[Zope-dev] Segfault and Deadlock

[Tim Peters]

[Willi.Langenberger at wu-wien.ac.at]
> Hi Zope (and Python) experts!
>
> There seems to be a problem when an external python module segfaults
> during a zope request. The remaining worker threads are deadlocked.

Maybe, maybe not.  Python (and so also Zope) use platform-native thread
facilities, and what happens when SIGSEGV gets signaled is mostly up to
them.  That's why you see different behavior, e.g., between Linux with NPTL
and Linux without NPTL:  the OS and C runtime determine exceptional thread
semantics, and Python isn't the operating system.

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.  The "natural" (least effort)
behavior is for the system to kill off the thread simply ignoring whatever
resources it may be holding.  In that case, all Python threads remaining
will hang forever waiting to acquire the GIL.

I expect the best that can be done, short of heroic effort (like writing
your own platform thread implementation), is to document what the various
thread implementations actually do.

> ...
> The reason is the way python handles threads on some systems
> (RedHat-7.3, kernel 2.4.20, without NPTL).

If you search the Python implementation, you'll find that there's nothing
different in what Python does depending on whether NPTL is present.  On any
system, all Python asks of the platform thread gimmicks is (a) a way to
start a thread, and (b) a way to implement Python lock semantics.  On any
POSIX system, #b is done with POSIX semaphores

#if defined(_POSIX_SEMAPHORES) && !defined(HAVE_BROKEN_POSIX_SEMAPHORES)

else #b is done with a combination of POSIX mutexes and POSIX condition
variables.  It could be that whether POSIX semaphores are available on Linux
depends on whether NPTL is in place -- I don't know.  But if so, that may be
the relevant difference.