Author martin.panter
Recipients docs@python, martin.panter, petr@motejlek.net
Date 2017-01-25.22:48:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1485384505.0.0.443124014535.issue29374@psf.upfronthosting.co.za>
In-reply-to
Content
This works for me on Linux:

>>> signal.pthread_sigmask(signal.SIG_BLOCK, {signal.SIGUSR1})
set()
>>> import threading
>>> t = threading.Thread(target=sigwait)
>>> t.start()
Send me a signal, my PID is 24197
>>> os.kill(os.getpid(), signal.SIGUSR1)
Got the signal: 10
>>> t.join()

Posix <http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigwait.html> only defines sigwait() if the signals are already blocked. Two reasons behind this come to mind:

1. There would be a race where the signal handler may be called first (or the signal may be ignored) at the OS level, and the sigwait() function will miss the signal and block.

2. If the signal is handled in the context of another thread that isn’t using sigwait(), it may be consumed (handled or ignored) in the context of the other thread, with no effect on your sigwait() call.

This detail of blocking the signal seems to be a common error, so maybe the Python documentation could help point it out. (Issue 25868 comes to mind; there is a test case that IMO should block a signal before waiting for it.)
History
Date User Action Args
2017-01-25 22:48:25martin.pantersetrecipients: + martin.panter, docs@python, petr@motejlek.net
2017-01-25 22:48:25martin.pantersetmessageid: <1485384505.0.0.443124014535.issue29374@psf.upfronthosting.co.za>
2017-01-25 22:48:24martin.panterlinkissue29374 messages
2017-01-25 22:48:24martin.pantercreate