[Windows] asyncio: support signal handlers on Windows (feature request)

[asvetlov]

BPO	23057
Nosy	@akuchling, @vstinner, @tjguk, @jkloth, @asvetlov, @zware, @1st1, @zooba, @DMRobertson, @Kwpolska
PRs	bpo-23057: add loop self socket as wakeup fd for signals #11135 bpo-23057: Use 'raise' to emulate ctrl-c in proactor tests #11274

^{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:

assignee = None
closed_at = <Date 2018-12-18.21:58:01.757>
created_at = <Date 2014-12-15.20:10:56.825>
labels = ['type-feature', '3.8', 'OS-windows', 'expert-asyncio']
title = '[Windows] asyncio: support signal handlers on Windows (feature request)'
updated_at = <Date 2019-01-05.20:45:03.021>
user = 'https://github.com/asvetlov'

bugs.python.org fields:

activity = <Date 2019-01-05.20:45:03.021>
actor = 'asvetlov'
assignee = 'none'
closed = True
closed_date = <Date 2018-12-18.21:58:01.757>
closer = 'asvetlov'
components = ['Windows', 'asyncio']
creation = <Date 2014-12-15.20:10:56.825>
creator = 'asvetlov'
dependencies = []
files = []
hgrepos = []
issue_num = 23057
keywords = ['patch']
message_count = 12.0
messages = ['232678', '232770', '232772', '232865', '232866', '240645', '246316', '246428', '246441', '332088', '332769', '333073']
nosy_count = 12.0
nosy_names = ['akuchling', 'vstinner', 'tim.golden', 'jkloth', 'asvetlov', 'zach.ware', 'yselivanov', 'Drekin', 'steve.dower', 'Kimmo.Parviainen-Jalanko', 'David Robertson', 'Kwpolska']
pr_nums = ['11135', '11274']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue23057'
versions = ['Python 3.8']

[asvetlov]

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

[vstinner]

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.

[vstinner]

This issue is specific to Windows. On all others platforms, signal handling is nicely supported.

[KimmoParviainen-Jalanko]

Seems to happen on FreeBSD 10.1 as well with 3.4.2

[vstinner]

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.

[akuchling]

Victor's patch has moved to python/asyncio#191 .

[Drekin]

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.

[DMRobertson]

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.

[Drekin]

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.