Currently, test_eintr is complelty skipped on Windows. time.sleep() was also patched on Windows to retry when interrupted by a signal (issue #23646) and I was able to see a different when testing manually.

test_eintr is currently implemented with signal.setitimer() and os.fork(). Windows doesn't have signal.setitimer(), signal.alarm(), nor os.fork(), but it's possible to send a signal to another process using os.kill() (by the way, see the issue #14484 "missing return in win32_kill?").

At least, time.sleep() should be tested on Windows.

Here's the 1st draft of a test for interrupts during time.sleep().  It creates a thread to generate the ctrl-c events which seems to work well (note that kill() on win32 is quite limited in terms of sending events to other processes).  The creation and use of the subthread probably could be improved.  I also needed to add a way of specifying creationflags for a subprocess so a new console could be created; otherwise the parent test process is also interrupted by the ctrl-c.

I have not tested the modified test on a non-win32 platform

The change ed0e6a9c11af replaced os.fork() with subprocess to try to fix race conditions in test_eintr (the test sometimes hangs on FreeBSD buildbots). os.fork() is not available on Windows, so this change should help to port test_eintr to Windows.

About win32-sleep-test.diff: I'm not sure that it's a good idea to introduce a new thread in test_eintr. Signal handlers is more complex when we have multiple threads. Would it be possible to spawn a new process which will send a signal every N seconds to its parent?

Sorry, I lost track of this idea, and I was unable to review win32-sleep-test.diff :-( While it would be "nice to have", the code is well tested on Unix. I close the issue.

stage: resolved

nosy: + jpe
messages: + msg240823

keywords: + patch