[Python-Dev] Threading bug review + commit privs
Reid Kleckner
reid.kleckner at gmail.com
Sun Jul 11 15:23:13 CEST 2010
Hey all,
I'm porting some fixes for threading.py that we applied to unladen-swallow:
http://bugs.python.org/issue6643
We ran into these bizarre race conditions involving fork + threads
while running the test suite with a background JIT compilation thread.
I really wish we weren't trying to support forking from a child
thread, but it's already in the test suite. I've "solved" the problem
by throwing away radioactive locks that may have been held across a
fork.*
If I could get a reviewer to look at this, I would be very grateful,
since reviewing threading patches is somewhat tricky. =/
I'm also expecting to be doing more work merging unladen-swallow into
the py3k-jit branch, so I was wondering if I could get commit
privileges for that.
Thanks,
Reid
* In general I wouldn't think this is safe, but we already do it for
_active_limbo_lock in threading.py. One of the problems I've
encountered is that on OS X, releasing locks held by other threads
across a fork results in a crash. Furthermore, when locks are
deallocated, the destructor does a non-blocking acquire and then
release, which I would think would crash. However, we get lucky here,
because any thread that holds a lock across a fork usually holds a
reference to it on the stack. Therefore the lock is leaked and the
destructor never run. Moral: fork + threads is *crazy*, avoid it if
you can.
More information about the Python-Dev
mailing list