[Python-Dev] Signals, threads, blocking C functions

[Gustavo Carneiro]

On 9/2/06, Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:
> > According to [1], 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
should just
| 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
doesn't happen!

>
> >   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
failing now.

  Anyway, attached a patch that should fix the problem in posix
threads systems, in case anyone wants to review.

  Cheers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pythreads.diff
Type: text/x-patch
Size: 1030 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20060902/b91250df/attachment.bin