[Patches] [Patch #101226] make threading fork-safe

[noreply@sourceforge.net]

Patch #101226 has been updated. 

Project: 
Category: core (C code)
Status: Open
Summary: make threading fork-safe

Follow-Ups:

Date: 2000-Aug-18 21:46
By: cgw

Comment:
See http://www.lambdacs.com/newsgroup/FAQ.html#Q120
and "man pthread_atfork" for background.

I don't use a pthread_atfork handler here - the explicit
approach is more portable.  However calling fork() from
C extensions could still cause trouble.

This patch causes the child to create a new interpreter
lock after doing a fork.  It would be nice to deallocate
the old lock with PyThread_free_lock, but this does some
unwanted error-checking in addition to deallocating the
lock.  So I waste a little memory instead.  To really do
this cleanly one could add a new PyThread_reset_lock function to all the thread_*.h files, and use that instead.


-------------------------------------------------------

Date: 2000-Aug-19 18:51
By: tim_one

Comment:
Assigned to me.  I'll discuss it with Guido too.  So far 2e've gotten 3 reports from people who don't see failures in assorted test cases anymore, and no reports of remaining failures.
-------------------------------------------------------

Date: 2000-Aug-24 11:02
By: tim_one

Comment:
Accepted, and assigned to Jeremy for checkin.
We may (or may not) want to bulletproof more locks for 2.0b1, but this has certainly helped so far and done no harm.  Jeremy, I don't feel comfortable trying to check in the change myself, as I can't run test_fork1 (or any other fork test) on Windows.
-------------------------------------------------------

Date: 2000-Aug-24 11:19
By: tim_one

Comment:
Accepted, and assigned to Jeremy for checkin.
We may (or may not) want to bulletproof more locks for 2.0b1, but this has certainly helped so far and done no harm.  Jeremy, I don't feel comfortable trying to check in the change myself, as I can't run test_fork1 (or any other fork test) on Windows.
-------------------------------------------------------

Date: 2000-Aug-24 20:06
By: gvanrossum

Comment:
Don't check this in yet!

Tim & I had a brainwave. We can share a single mutex for all locks and grab it around a fork, and the lock reinitialization won't be needed.

(We think.)
-------------------------------------------------------

Date: 2000-Aug-24 21:09
By: tim_one

Comment:
Now that I've had a chance to drive recklessly, suck down a Coke, and chain-smoke two butts in peace <wink>, I'm certain that the "one mutex" idea will work, and satisfied that the extra contention it may cause is pthread's own damn fault for presuming to kill threads in the child while they're in an unknown state.  Full mutex ahead!
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101226&group_id=5470