Message279565
From my perspective the problem is: many asyncio calls schedules a delayed activity internally.
E.g. `task.cancel()` doesn't cancels immediately but requires at least one extra loop iteration.
The same is true for `transport.close()` -- it doesn't close socket in the call.
This behavior is encouraged by asyncio design and many third-party libraries just call `transp.close()` without waiting for upcoming `protocol.connection_lost()` callback.
I don't think it's a big problem, especially for server code.
But when users write small client tool they need to do extra no-op loop iterations before `loop.close()` call.
Waiting for no scheduled by `loop.call_soon()` callbacks makes no sense I believe. I could open a can of worms by introducing another weird side effects. |
|
Date |
User |
Action |
Args |
2016-10-27 19:32:57 | asvetlov | set | recipients:
+ asvetlov, r.david.murray, docs@python, yselivanov, Константин Волков |
2016-10-27 19:32:57 | asvetlov | set | messageid: <1477596777.17.0.576831471398.issue28212@psf.upfronthosting.co.za> |
2016-10-27 19:32:57 | asvetlov | link | issue28212 messages |
2016-10-27 19:32:56 | asvetlov | create | |
|