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. -- Dieter