classification
Title: Closing server in asyncio is not efficient
Type: Stage: resolved
Components: asyncio, Documentation Versions: Python 3.6, Python 3.5
process
Status: closed Resolution: duplicate
Dependencies: Superseder: Add StreamWriter.wait_closed()
View: 32391
Assigned To: docs@python Nosy List: asvetlov, docs@python, r.david.murray, yselivanov, Константин Волков
Priority: normal Keywords:

Created on 2016-09-20 09:10 by Константин Волков, last changed 2017-12-21 09:28 by asvetlov. This issue is now closed.

Files
File name Uploaded Description Edit
task_example.py Константин Волков, 2016-09-20 16:33
Messages (12)
msg277019 - (view) Author: Константин Волков (Константин Волков) Date: 2016-09-20 09:10
When you close asyncio socket server it closes all connection sockets, remove its readers and do "cancel" for readers. Problem is that, that after this reader tasks are leaved alone in "cancelling" state. They wouldn`t be really cancelled, because they need a loop step for that. But they are not in loop now(they suggest execution throught selector, but they not presented there after removal). Cancelling step woldn`t be done and tasks wouldn`t be really finished, and no finishing actions can be done.
I think that It is good idea such tasks to "ready" queue, so they can be executed in normal task way after removing from selector.
msg277029 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-09-20 14:50
You have to call wait_closed to complete the shutdown.

This should probably be mentioned directly in the socket server docs (at least in the examples) (assuming I'm not wrong...but I'm pretty sure I'm right) rather than by implicit reference to Server via the create_server comment.
msg277031 - (view) Author: Константин Волков (Константин Волков) Date: 2016-09-20 15:06
Thats not a thing I talking about. But thanks for "wait_closed", I will be
use it in future )

Im talking about reading tasks.When reader removed from selector, there is
reading task for it. Loop do "cancel" for it, but it not really cancelling
task. Its only marking task for be cancelled on next loop step. It must
raise Cancel exception, so task may do corresponding actions inside it (for
exemple try..except Cancel). But it will not happen, because there will be
no next step - task removed from selector and now is missed from loop. It
will freese in "cancelling" state forever if protocol implementation
wouldn`t take care about it itself. Some protocol implementations make
"_step" for such tasks manually to loop them for correct finishing, someone
makes "set_result(None)", but its all looks bad.
Seems it will be better put it in loop after removing from selector, so it
will go "cancelling way" itself as every task do.

2016-09-20 17:50 GMT+03:00 R. David Murray <report@bugs.python.org>:

>
> R. David Murray added the comment:
>
> You have to call wait_closed to complete the shutdown.
>
> This should probably be mentioned directly in the socket server docs (at
> least in the examples) (assuming I'm not wrong...but I'm pretty sure I'm
> right) rather than by implicit reference to Server via the create_server
> comment.
>
> ----------
> assignee:  -> docs@python
> components: +Documentation
> nosy: +docs@python, r.david.murray
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue28212>
> _______________________________________
>
msg277032 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2016-09-20 15:12
Can you please supply a complete example?

--Guido (mobile)
msg277034 - (view) Author: Константин Волков (Константин Волков) Date: 2016-09-20 15:15
Yes? may be a in a hour,

2016-09-20 18:12 GMT+03:00 Guido van Rossum <report@bugs.python.org>:

>
> Guido van Rossum added the comment:
>
> Can you please supply a complete example?
>
> --Guido (mobile)
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue28212>
> _______________________________________
>
msg277041 - (view) Author: Константин Волков (Константин Волков) Date: 2016-09-20 16:33
Attached file with test example. There in "ping" task "except" and "finally" sections never called as expected (but code inside "try" will work).
Server is closed while client connection is active, and it just removes reading task from loop. You can still find it through Task.all_tasks(), but it is weakref array. So, sometime later GC will simply delete this task and no finalization will be performed.
msg277061 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2016-09-20 20:16
It's a known annoying issue.
Honestly I don't know how to fix it properly.
`transport.close()` is affected also because `protocol.connection_lost()` is called on next loop iteration only.

Adding a small `asyncio.sleep()` between finishing all worn and loop closing solves the problem for me but the solution is not obvious for newbies.
msg277062 - (view) Author: Константин Волков (Константин Волков) Date: 2016-09-20 20:23
Seems that its not so hard - in loop.remove_reader add

self._ready.append(reader)

after reader.cancel()

May be its needed to check that its not already there, but I cant imagine
how it can be.

2016-09-20 23:16 GMT+03:00 Andrew Svetlov <report@bugs.python.org>:

>
> Andrew Svetlov added the comment:
>
> It's a known annoying issue.
> Honestly I don't know how to fix it properly.
> `transport.close()` is affected also because `protocol.connection_lost()`
> is called on next loop iteration only.
>
> Adding a small `asyncio.sleep()` between finishing all worn and loop
> closing solves the problem for me but the solution is not obvious for
> newbies.
>
> ----------
> nosy: +asvetlov
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue28212>
> _______________________________________
>
msg279153 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2016-10-21 21:06
> Seems that its not so hard - in loop.remove_reader add

If you have a patch in mind, please create a PR on github.com/python/asyncio
msg279500 - (view) Author: Константин Волков (Константин Волков) Date: 2016-10-26 14:10
Seems that my example wasn`t good. Real reason in it was that closing server is not closing already established connections, and seems that it is not expected to do.
Andrew, can you provide your example? I catched some problems but now I think it was because of asyncio internal logic misunderstanding. May be if you provide your example there will be some ideas.
msg279565 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2016-10-27 19:32
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.
msg308862 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2017-12-21 09:28
Superseded by https://bugs.python.org/issue32391
History
Date User Action Args
2017-12-21 09:28:56asvetlovsetstatus: open -> closed
superseder: Add StreamWriter.wait_closed()
messages: + msg308862

resolution: duplicate
stage: resolved
2016-10-27 19:32:57asvetlovsetmessages: + msg279565
2016-10-26 14:10:35Константин Волковsetmessages: + msg279500
2016-10-21 21:06:03yselivanovsetmessages: + msg279153
2016-09-20 20:30:27gvanrossumsetnosy: - gvanrossum
2016-09-20 20:23:03Константин Волковsetmessages: + msg277062
2016-09-20 20:16:24asvetlovsetnosy: + asvetlov
messages: + msg277061
2016-09-20 16:33:13Константин Волковsetfiles: + task_example.py

messages: + msg277041
2016-09-20 15:15:49Константин Волковsetmessages: + msg277034
2016-09-20 15:12:26gvanrossumsetmessages: + msg277032
2016-09-20 15:06:57Константин Волковsetmessages: + msg277031
2016-09-20 14:50:13r.david.murraysetnosy: + r.david.murray, docs@python
messages: + msg277029

assignee: docs@python
components: + Documentation
2016-09-20 09:10:08Константин Волковcreate