Author Ben.Darnell
Recipients Ben.Darnell, Jonathan Slenders, asvetlov, cjrh, yselivanov
Date 2020-02-16.15:05:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1581865506.91.0.716907275023.issue39010@roundup.psfhosted.org>
In-reply-to
Content
I just spent some time digging into this. Each call to `run_forever` starts a call to `_loop_self_reading`, then attempts to cancel it before returning:

https://github.com/python/cpython/blob/1ed61617a4a6632905ad6a0b440cd2cafb8b6414/Lib/asyncio/windows_events.py#L312-L325

The comment at line 321 is not entirely accurate: the future will not resolve in the future, but it may have *already* resolved, and added its callback to the call_soon queue. This callback will run if the event loop is restarted again. Since `_loop_self_reading` calls itself, this results in two copies of the "loop" running concurrently and stepping on each other's `_self_reading_futures`. 

This appears to be fairly harmless except for noise in the logs when only one of the loops is stopped cleanly.

I believe the simplest fix is for `_loop_self_reading` to compare its argument to `self._self_reading_future` to determine if it is the "current" loop and if not, don't reschedule anything.
History
Date User Action Args
2020-02-16 15:05:06Ben.Darnellsetrecipients: + Ben.Darnell, asvetlov, cjrh, yselivanov, Jonathan Slenders
2020-02-16 15:05:06Ben.Darnellsetmessageid: <1581865506.91.0.716907275023.issue39010@roundup.psfhosted.org>
2020-02-16 15:05:06Ben.Darnelllinkissue39010 messages
2020-02-16 15:05:06Ben.Darnellcreate