Tim Peters wrote at 2004-5-2 23:16 -0400:
>Suppose a thread dies while holding the GIL (Python's global interpreter
>lock). Will the GIL be released so that another thread (including the main
>thread) can continue? There's no general answer to that. I expect that
>under *most* platform threading implementations, all threads will be dead in
>the water then, because threads are intentionally (by the OS and C runtime)
>lightweight objects under most implementations, and don't save away enough
>info to make it *possible* for the platform thread runtime to recover
>gracefully in case of thread disaster.
That would not be necessary as long as all threads die.
The reason why I believe Python is to blame:
With Python 2.1.3, a SIGSEGV in one thread killed them all;
with Python 2.3.3, a SIGSEGV in one thread kills one
of them (the main thread, not the thread that got the SIGSEGV)
but brings the others in a funny state.
This is on the same OS (Linux 2.4 kernel without NPTL).
Apparently, Python's handling of SIGSEGV signals
changed between 2.1.3 and 2.3.3.
In an earlier post, someone reported that Python explicitely
blocks most signals in non-main threads.
I verified that in the SIGSEGV case above, all remaining threads
had "SIGSEGV" blocked.
I may try to change Python to not block SIGSEGV and see
whether we get again the old Python 2.1.3 behaviour.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -