On 19.12.2015 20:25, Guido van Rossum wrote: > Perhaps you can add a check for a simple boolean 'stop' flag to your > condition check, and when you want to stop the loop you set that flag > and then call notify() on the condition. Then you can follow the > standard condition variable protocol instead of all this nonsense. :-) Your example does not work. > def stop_it(self): > self.stopped = True > self.uptodate.notify() self.uptodate needs to be locked before I can call .notify() on it. Creating a new task just for that seems like overkill, and I'd have to add a generation counter to prevent a race condition. Doable, but ugly. However, this doesn't fix the generic problem; Condition.wait() was just what bit me today. When a non-async generator goes out of scope, its finally: blocks will execute. An async procedure call whose refcount reaches zero without completing simply goes away; finally: blocks are *not* called and there is *no* warning. I consider that to be a bug. -- -- Matthias Urlichs
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4