FWIW I should mention that this is totally within the vague spec of PEP 3156 for stop():
- ``stop()``. Stops the event loop as soon as it is convenient. It is fine to restart the loop with ``run_forever()`` or ``run_until_complete()`` subsequently; no scheduled callbacks will be lost if this is done. Note: ``stop()`` returns normally and the current callback is allowed to continue. How soon after this point the event loop stops is up to the implementation, but the intention is to stop short of polling for I/O, and not to run any callbacks scheduled in the future; the major freedom an implementation has is how much of the "ready queue" (callbacks already scheduled with ``call_soon()``) it processes before stopping. I would love to hear from people who have tried this patch on various platforms. On Tue, Nov 17, 2015 at 4:35 PM, Guido van Rossum <gu...@python.org> wrote: > In this issue: http://bugs.python.org/issue25593 there's a proposal to > change the semantics of stop(). I'm looking for feedback about whether > this patch would negatively impact anyone. > > The key difference is that if you call stop() multiple times before > run_forever() actually stops, *currently* the next time that > run_forever() is called it will immediately stop again. With the > patch, multiple stop() calls will be redundant -- calling stop() will > only affect the current run_forever() invocation. Note that > run_until_complete() is implemented by combining run_forever() and > stop(). > > (Interestingly, because of the way _run_once() works, if a callback > calls call_soon(X) and then stop(), in the current version X will be > called before run_forever() returns; while with the patch, > run_forever() will return without calling X -- it will be called the > next time run_forever() is called.) > > Thoughts? > > -- > --Guido van Rossum (python.org/~guido) -- --Guido van Rossum (python.org/~guido)
