[Python-Dev] Threading bug review + commit privs (original) (raw)
Reid Kleckner reid.kleckner at gmail.com
Sun Jul 11 15:23:13 CEST 2010
- Previous message: [Python-Dev] Removing IDLE from the standard library
- Next message: [Python-Dev] commit privs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message: [Python-Dev] Removing IDLE from the standard library
- Next message: [Python-Dev] commit privs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]