Константин Волков added the comment: 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 <rep...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue28212> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28212> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
