[docs] [issue28212] Closing server in asyncio is not efficient

[Andrew Svetlov]

Andrew Svetlov added the comment:

>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.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28212>
_______________________________________