See http://stackoverflow.com/questions/27480967/why-does-the-asyncios-event-loop-suppress-the-keyboardinterrupt-on-windows for details

Hi, I started to work on this topic a few months ago:
https://code.google.com/p/tulip/issues/detail?id=191

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

> 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 https://github.com/python/tulip/issues/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:
https://docs.python.org/3/library/asyncio-protocol.html#protocol-examples
I copied the two examples from the docs into `server.py' and `client.py'. I ran server.py first and hit control-C. This did not close the server as expected. However, if I then ran client.py, the act of sending a message to the server seemed to prompt it to receive the KeyboardInterrupt and close! In turn this caused an OSError to be raised by the client.

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.

New changeset b5c8cfa1da17c6f3acac80a0afca7f7104fb9589 by Andrew Svetlov (Vladimir Matveev) in branch 'master':
bpo-23057: add loop self socket as wakeup fd for signals (#11135)
https://github.com/python/cpython/commit/b5c8cfa1da17c6f3acac80a0afca7f7104fb9589

GH-11274 desperately needs to be addressed! The 2 Windows 7 buildbots have been failing on 3.x since the merge of GH-11135 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.

New changeset 67ba547cf001d6b975cf6900aaf2bd5508dc6a87 by Andrew Svetlov (Vladimir Matveev) in branch 'master':
bpo-23057: Use 'raise' to emulate ctrl-c in proactor tests (#11274)
https://github.com/python/cpython/commit/67ba547cf001d6b975cf6900aaf2bd5508dc6a87