This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rpurdie
Recipients gregory.p.smith, rpurdie
Date 2022-04-05.19:28:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1649186889.39.0.168924890074.issue47139@roundup.psfhosted.org>
In-reply-to
Content
I think the python code implementing pthread_sigmask already does trigger interrupts if any have been queued before the function returns from blocking or unblocking.

The key subtlety which I initially missed is that if you have another thread in your python script, any interrupt it receives can be raised in the main thread whilst you're in the SIGBLOCK section. This obviously isn't what you expect at all as those interrupts are supposed to be blocked! It isn't really practical to try and SIGBLOCK on all your individual threads.

What I'd wondered is what you mention, specifically checking if a signal is masked in the python signal raising code with something like the "pthread_sigmask(SIG_UNBLOCK, NULL /* set */, &oldset)" before it raises it and if there is blocked, just leave it queued. The current code would trigger the interrupts when it was unmasked. This would effectively only apply on the main thread where all the signals/interrupts are raised. 

This would certainly give the behaviour that would be expected from the calls and save everyone implementing the workarounds as I have. Due to the threads issue, I'm not sure SIGBLOCK is actually useful in the real world with the current implementation unfortunately.

Equally, if that isn't an acceptable fix, documenting it would definitely be good too.
History
Date User Action Args
2022-04-05 19:28:09rpurdiesetrecipients: + rpurdie, gregory.p.smith
2022-04-05 19:28:09rpurdiesetmessageid: <1649186889.39.0.168924890074.issue47139@roundup.psfhosted.org>
2022-04-05 19:28:09rpurdielinkissue47139 messages
2022-04-05 19:28:09rpurdiecreate