This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients bquinlan, dmalcolm, jnoller, kristjan.jonsson, lukasz.langa, neologix, pitrou, sandro.tosi, ysj.ray
Date 2011-04-27.15:30:23
SpamBayes Score 3.4917844e-09
Marked as misclassified No
Message-id <1303918225.0.0.374756441876.issue10517@psf.upfronthosting.co.za>
In-reply-to
Content
> Ah, using the fallback implementation of tls?  Surely this isn't a 
> problem with the pthreads tls, I'd be surprised if it retains TLS values 
> after fork.

It surprised me too when I found that out, but it's really with the pthread TLS, on RHEL 4 and 5 (fixed in RHEL6).
See the attached test_specific.c test script.

> You could add a new _PyGILState_ReInit() function and call it from
> PyOS_AfterFork() or PyEval_ReInitThreads().

See attached tls_reinit.diff patch.
But I really find this redundant with PyThread_ReInitTLS, because what we're really doing is reinit the TLS.
Also, this calls this for every thread implementation, while it's only necessary for pthreads (and for other implementation it will redo the work done by PyThread_ReInitTLS).
So I've written another patch which does this in pthread's PyThread_ReInitTLS.

You've got much more experience than me, so it's really your call.
Actually, I kind of feel bad for adding such a hack for a pthread's bug affecting only RHEL 4 and 5, I'm wondering whether it's really worth fixing it.
History
Date User Action Args
2011-04-27 15:30:25neologixsetrecipients: + neologix, bquinlan, pitrou, kristjan.jonsson, jnoller, dmalcolm, sandro.tosi, ysj.ray, lukasz.langa
2011-04-27 15:30:25neologixsetmessageid: <1303918225.0.0.374756441876.issue10517@psf.upfronthosting.co.za>
2011-04-27 15:30:24neologixlinkissue10517 messages
2011-04-27 15:30:24neologixcreate