-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Windows] asyncio: support signal handlers on Windows (feature request) #67246
Comments
Hi, I started to work on this topic a few months ago: I should update my patches. |
This issue is specific to Windows. On all others platforms, signal handling is nicely supported. |
Seems to happen on FreeBSD 10.1 as well with 3.4.2 |
FreeBSD uses a completly different implementation. Please open a new issue, describe your problem and write a script reproducing your issue. |
Victor's patch has moved to python/asyncio#191 . |
I've also run into this issue (see https://mail.python.org/pipermail/python-list/2015-July/693496.html and the following thread). I'm adding some small examples showing the behavior. import asyncio
async def wait():
await asyncio.sleep(5)
loop = asyncio.get_event_loop()
loop.run_until_complete(wait()) The following even smaller example by Terry Reedy and the OP from http://stackoverflow.com/questions/27480967/why-does-the-asyncios-event-loop-suppress-the-keyboardinterrupt-on-windows cannot be interrupted other way then shuting down whole process: asyncio.get_event_loop().run_forever() --- It would be nice the patch mentioned was eventually applied. |
Dear all, I have just been trying to understand the TCP Echo example from the asyncio documentation: Some searching lead me to StackOverflow and then to this bug. I wanted to point out this behaviour, as I didn't see it mentioned in any of the previous comments. Plus, I thought it was a shame that the first example I looked didn't behave as described! I'm curently running Python 3.3.1 on Windows 7 and I'm using asyncio 3.4.3 from PyPI. |
David Robertson: The behaviour you pointed out is a consequence of the general issue: signals on Windows aren't fully supported. Basically, they cannot interrupt the event loop when every coroutine is waiting for something. Instead, they are fired when something happens – some data are recieved or some timer reaches zero. In your case it was the connection of the client or the message it sent. This is the right issue related to your problem. Hopefully, it will be fixed eventually. A current workaround is to schedule a task which periodically sleeps for an amount of time. For example, if it allways sleeps for one second, then you will wait for KeyboardInterrupt at most one second. |
#55483 desperately needs to be addressed! The 2 Windows 7 buildbots have been failing on 3.x since the merge of #55344 on 12-18. Either that or the commit b5c8cfa needs to be reverted. Being the holiday season and all I can see the extra time needed for Python development is sparse, but 2 weeks without ensuring a commit doesn't break stable buildbots seems a bit much. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: