[Python-Dev] Signals, threads, blocking C functions
gjcarneiro at gmail.com
Sat Sep 2 18:39:51 CEST 2006
On 9/2/06, Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:
> > According to , all python needs to do to avoid this problem is
> > block all signals in all but the main thread; then we can guarantee
> > signal handlers are always called from the main thread, and pygtk
> > doesn't need a timeout.
> 1) That page is password protected, so I can't see what it says, and
> am disinclined to register myself to yet another such site.
Oh, sorry, here's the comment:
(coment by Arjan van de Ven):
| afaik the kernel only sends signals to threads that don't have them blocked.
| If python doesn't want anyone but the main thread to get signals, it
| block signals on all but the main thread and then by nature, all
signals will go
| to the main thread....
> 2) No way, Jose, anyway. The POSIX signal handling model was broken
> beyond redemption, even before threading was added, and the combination
> is evil almost beyond belief. That procedure is good practice, yes,
> but that is NOT all that you have to do - it may be all that you CAN
> do, but that is not the same.
> Nope. Sorry, but you can't solve a broken design by adding interfaces.
Well, Python has a broken design too; it postpones tasks and expects
to magically regain control in order to finish the job. That often
> > But I would really prefer the first alternative, as it could be
> > fixed within python 2.5; no need to wait for 2.6.
> It clearly should be done, assuming that Python's model is that it
> doesn't want to get involved with subthread signalling (and I really,
> but REALLY, recommend not doing so). The best that can be done is to
> say that all signal handling is the business of the main thread and
> that, when the system bypasses that, all bets are off.
Python is halfway there; it assumes signals are to be handled in the
main thread. However, it _catches_ them in any thread, sets a flag,
and just waits for the next opportunity when it runs again in the main
thread. It is precisely this "split handling" of signals that is
Anyway, attached a patch that should fix the problem in posix
threads systems, in case anyone wants to review.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1030 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20060902/b91250df/attachment.bin
More information about the Python-Dev