On Fri, Dec 18, 2015 at 10:25 AM, Szieberth Ádám <sziebadam at 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20151218/2fac17f7/attachment-0001.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4