> 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4