Message134476
| Author |
pitrou |
| Recipients |
bquinlan, dmalcolm, jnoller, kristjan.jonsson, lukasz.langa, neologix, pitrou, sandro.tosi, ysj.ray |
| Date |
2011年04月26日.16:26:18 |
| SpamBayes Score |
1.3162249e-11 |
| Marked as misclassified |
No |
| Message-id |
<1303835169.3518.19.camel@localhost.localdomain> |
| In-reply-to |
<1303834808.9.0.968329581521.issue10517@psf.upfronthosting.co.za> |
| Content |
> > How about deleting the mapping (pthread_key_delete) and recreating it
> > from scratch, then?
>
> Sounds good.
> So the idea would be to retrieve the current thread's tstate, destroy
> the current autoTLSkey, re-create it, and re-associate the current
> tstate to this new key. I just did a quick test on RHEL4 and it works.
> PyThread_ReinitTLS looks like a good candidate for that, but it's the
> same problem, autoTLSkey scope is limited to pystates.c (and I'm not
> sure that the tstate should be exposed to platform thread
> implementations).
> There's also PyEval_ReinitThreads in ceval.c, exposing the autoTLSkey
> would make more sense (and it already knows about tstate, of course).
> Where would you put it?
You could add a new _PyGILState_ReInit() function and call it from
PyOS_AfterFork() or PyEval_ReInitThreads().
(perhaps you also need to add a TLS-destroying function to thread.c, I
haven't looked) |
|