Thanks for your reply Guido! > - Instead of calling signal.signal() yourself, you should use > loop.add_signal_handler(). It makes sure your signal handler doesn't run > while another handler is already running.
I was opted to the signal module because `signal` documentation suggest that it alos supports Windows while asyncio documentation states that `loop. add_signal_handler()` is UNIX only. > - I'm unclear on why you want a wait_forever() instead of using > loop.run_forever(). Can you clarify? As I see `loop.run_forever()` is an issue from _outside_ while an `await wait_forever()` would be an _inside_ declaration making explicit what the task does (serving forever). My OP suggest that it seemed to me quite helpful inside async context. However, I wanted to share my approach to get a confirmation that I am not on a totally wrong way with this. > - In theory, instead of waiting for a Future that is cancelled by a > handler, you should be able to use asyncio.sleep() with a very large number > (e.g. a million seconds). I was thinking on this too but it seemed less explicit to me than awaiting a pure Future with a short comment. Moreover, even millions of seconds can pass. > Your handler could then just call loop.stop(). For some reason I don't like bothering with the event loop from inside awaitables. It seems hacky to me since it breaks the hierarhy of who controlls who. > However, I just tested this and it raises "RuntimeError: Event loop stopped > before Future completed." so ignore this until we've fixed it. :-) This is the exception I saw so many times by trying to close an asyncio program! I guess I am not the only one. This may be one of the most frustrating aspects of the library. Yet, it inspired me to figure out a plain pattern to avoid it, which may not the right one. However, I would like to signal that it would be nice to help developers with useful patterns and documentation to avoid RuntimeErrors and the frustration that goes with them. Ádám (http://szieberthadam.github.io/) PS: I will replay to others as well, but first I had to play with my son. :) _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
