On Fri, Dec 18, 2015 at 10:25 AM, Szieberth Ádám <szieba...@gmail.com> wrote:
> 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. > Unfortunately that's true, but using the signal module with asyncio the way you did is *not* safe. The only safe way is to use the loop.add_signal_handler() interface. > > - 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. > Well, if you look at the toy servers in the asyncio examples directory, they all use run_forever(). I agree that from within the loop that's not possible, but I don't think it's such a common thing (you typically write a framework for creating servers once and that's the only place where you would need this). IOW I think your solution of waiting for a Future is the right way. > > - 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. > 11 years. That's quite some trust you put in your hardware... But you can use a billion. I think by 11000 years from now you can retire your server. :-) > > 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. > Fair enough -- you've actually internalized the asyncio philosophy quite well. > > 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. > Maybe you can help by submitting a patch that prevents this error! Are you interested? > Ádám > (http://szieberthadam.github.io/) > > PS: I will replay to others as well, but first I had to play with my son. > :) > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ 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
