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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com