[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

Guido van Rossum added the comment: When I removed myself from the nosy list I did mean to stop working on this bug, just that I am unlikely to be of any help. :-) -- nosy: +gvanrossum ___ Python tracker

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

Antoine Pitrou added the comment: That said, the pthread_kill() solution deserves testing as well. -- ___ Python tracker ___

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

Antoine Pitrou added the comment: > Using set_wakeup_fd would fix them... except that it generates spurious > warning messages when the wakeup fd buffer is full, and there's no way to > stop it Are you using a pipe or a socket to set_wakeup_fd? Pipes have rather small buffers. In any case,

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

Nathaniel Smith added the comment: Letting Python-level signal handlers run in arbitrary threads is an interesting idea, but it's a non-trivial change to Python semantics that may well break some programs (previously it was guaranteed that signal handlers couldn't race with main thread code),

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

STINNER Victor added the comment: I created a WIP patch https://github.com/python/cpython/pull/768 to experiment allowing signal handlers from any threads. I expect many race conditions since I only removed sanity checks without adding new code to handle parallelism. --

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

Changes by STINNER Victor : -- pull_requests: +675 ___ Python tracker ___ ___

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

STINNER Victor added the comment: thread_signal.py: Oops, I forgot to remove the "raise Exception" line from sighandler() (I used it for a quick test.) -- ___ Python tracker

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

STINNER Victor added the comment: Hum, maybe I found the root issue: the C signal handler calls Py_AddPendingCall() which uses a lock to protect a global static pendingcalls array (of 32 items). The function tries 100 times in a row to acquire to lock, or does nothing (returns -1) if it fails

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

STINNER Victor added the comment: Attached signal_pause_doesnt_wake_up.py is a little bit complex and not sure that it's reliable. I wrote thread_signal.py which should have a more deterministic behaviour. Output on Linux: --- main: main thread 140392674538560 thread: wait main: spawn thread

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

STINNER Victor added the comment: Nathaniel Smith added the comment: > In any case, the issue here remains that one shouldn't have to use > set_wakeup_fd for a signal to interrupt time.sleep etc. CPython implements a C signal handler which sets a flag and then exits immediately. The thread

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

Nathaniel Smith added the comment: @haypo: okay, looked over things over for a third time and this time I found my very silly error :-). So I'm now able to use set_wakeup_fd on Windows (https://github.com/python-trio/trio/pull/108), but not on Unix

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

Nathaniel Smith added the comment: @haypo: It's a socketpair. It works fine when I set up a toy test case using set_wakeup_fd + select, and it works fine in my real code when I use CFFI cleverness to register a signal handler that manually writes a byte to my wakeup socket, but when I pass

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

STINNER Victor added the comment: 2017-03-22 1:55 GMT+01:00 Nathaniel Smith : > + for some reason set_wakeup_fd doesn't work for me on Windows (no idea why, > can't reproduce in simplified tests, might be my fault, need to debug), I modified signal.set_wakeup_fd() to

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

Nathaniel Smith added the comment: I don't really have a specific use case personally -- for trio, I haven't found a way to make use of set_wakeup_fd because of various issues[1], but I'm also not planning to use SIGCHLD, so this isn't very urgent. In general set_wakeup_fd can be a

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

STINNER Victor added the comment: If the main thread waits on select() and uses a pipe with signal.set_wakeup_fd(), it should be fine. Is that your case? Asyncio requires to have an event loop running in the main thread to spawn child processes, to get SIGCHLD signals to get notified of child

[issue21895] signal.pause() and signal handlers don't react to SIGCHLD in non-main thread

Nathaniel Smith added the comment: It turns out that this bug is more general than signal.pause, and has caused problems for a few different people: https://github.com/dabeaz/curio/issues/118#issuecomment-287735781 https://github.com/dabeaz/curio/issues/118#issuecomment-287798241