Forking and Threads

[Tim Peters]

[posted & mailed]

[Paul Robinson]
> ...
> http://cobweb.quantisci.co.uk/pub/english.cgi/d10030658/forkingtest2.py
> ) will run happily for several minutes (upto about 10mins so far) and
> then just sit there with the main process running with as much CPU time
> as the OS will give it!
>
> ...
>
> I've only tested this on:
> Python 1.5.2
> Red Hat Linux release 6.2 (Zoot)
> Kernel 2.2.14-5.0smp on a 2-processor i686
>
> and would very interested in how (and if) it performs on other operating
> systems - obviously only those with both threading and forking need
> apply.

Try it under Python 2.0.  Similar problems were reported earlier, but only
(IIRC) under Linux.  A patch went into 2.0 that at least allowed Python's
own Lib/test/test_fork1.py to complete normally.  However, the behavior was
never fully understood; the best guess we were left with is that, across a
fork, the Linux flavor of mutexes and/or condition variables were mistakenly
still sharing some little of piece of internal state (Python's own basic
flavor of lock is implemented under pthreads via a mutex + condvar combo,
and after a fork the observed behavior of Python's internal "global
interpreter lock" didn't make any sense).  2.0 "fixed" that via brute force
panic:  after a fork, the child allocates a brand new interpreter lock for
its own use; it leaks the one inherited from the parent process.  Nobody was
able to do substantially better than this despite countless hours of trying,
so, under the assumption that it was a Linux bug that would eventually get
fixed, we all forgot about it.

blissfully-too<wink>-ly y'rs  - tim