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 pitrou
Recipients BreamoreBoy, Rhamphoryncus, bamby, duncf, exarkun, georg.brandl, gregory.p.smith, laca, movement, mstepnicki, neologix, nh2, pitrou, ross, vstinner
Date 2011-12-20.07:32:37
SpamBayes Score 4.5630166e-14
Marked as misclassified No
Message-id <1324366418.13.0.348248918392.issue1975@psf.upfronthosting.co.za>
In-reply-to
Content
>  1. On FreeBSD, we must assume that every blocking system call, in *every thread*, can be interrupted, and we need to catch EINTR.
> 
>  2. On FreeBSD, we cannot block indefinitely in the main thread and expect to handle signals. This means that indefinite selects are not possible if we want to handle signals, and, perhaps more perversely, signal.pause() cannot be reliably used in the main thread.

Well, I agree it makes matters more complicated, but if FreeBSD decides this behaviour is desireable, why would Python try to work around it?
To solve the select() problem you can have the signal handler write on a pipe (using signal.set_wakeup_fd (*)) and the select() call wait on that pipe. This also should allow to emulate signal.pause() (basically a select() with only the signal pipe).

IMHO, the general idea of Unix signals is a low-level kludge and any attempt to make it sane at the Python level is probably doomed to failure. Other synchronization methods should always be preferred, if possible.

(*) Linux has signalfd, but we don't expose it yet
History
Date User Action Args
2011-12-20 07:33:38pitrousetrecipients: + pitrou, georg.brandl, gregory.p.smith, exarkun, Rhamphoryncus, vstinner, movement, ross, bamby, laca, duncf, mstepnicki, nh2, neologix, BreamoreBoy
2011-12-20 07:33:38pitrousetmessageid: <1324366418.13.0.348248918392.issue1975@psf.upfronthosting.co.za>
2011-12-20 07:32:37pitroulinkissue1975 messages
2011-12-20 07:32:37pitroucreate