[Python-Dev] Re: Revised 1.6 jobs list

[Mark Hammond]

> I tried to reproduce the problem with a C program but could not.
> When things hang the forking thread is stuck in wait4() while the
> child process is suspended:

This looks very suspect.

>
>     #0  0x4027d9ba in sigsuspend () from /lib/libc.so.6
>     #1  0x40232c77 in __pthread_wait_for_restart_signal ()
>        from /lib/libpthread.so.0
>     #2  0x4023406e in __pthread_lock () from /lib/libpthread.so.0
>     #3  0x4023186a in pthread_mutex_lock () from /lib/libpthread.so.0
>     #4  0x806fbaa in PyThread_release_lock (lock=0x81ebb68) at
>     thread_pthread.h:339
>     #5  0x805617b in eval_code2 (co=0x81eca68, globals=0x81c4f64,

And very much like the Python thread-state is not being managed correctly
with fork.  From my understanding of fork (which is small), and of the
Python thread-state management, this doesnt surprise me.

Given the stack trace, it appears that Python is doing its periodic
thread-release as part of running around the main loop.

In the process of _releasing_ the thread-lock, it needs to _acquire_ a
mutex.  I dont know the Python threading on pthreads at all - would this be
correct (it would seem likely that such an implementation would be done).

But in the process of acquiring that mutex, we call

__pthread_wait_for_restart_signal()

Is it possible that is is something as simple as thread-idents changing
underneath Python when using fork?  It seems to me that the thread thinks
it is either new, or stale?

Just my 2c worth - and given my knowledge of Linux and pthreads, plus the
state of our dollar at the moment, it has better be AUD $0.02 :-)

Mark.