Message134573
| Author |
pitrou |
| Recipients |
bquinlan, dmalcolm, jnoller, kristjan.jonsson, lukasz.langa, neologix, pitrou, sandro.tosi, ysj.ray |
| Date |
2011年04月27日.14:57:55 |
| SpamBayes Score |
2.1375618e-08 |
| Marked as misclassified |
No |
| Message-id |
<1303916246.3591.2.camel@localhost.localdomain> |
| In-reply-to |
<1303915253.47.0.0442754855539.issue10517@psf.upfronthosting.co.za> |
| Content |
> Antoine, I wonder if we can restore PyThread_set_key_value to behave
> like a canonical TLS api function (always setting) but fix the cases
> that want to "set if it has not already been set" like the cases you
> mention.
> It is very unorthodox to have such "only set if it hasn't been set
> before" built into your only TLS function. This wart on python's TLS
> api has bugged me for yearsand it would be cool to fix it.
Well, these functions are supposed to be private so, while I agree their
behaviour is a bit unusual, I'm not sure there's any point to "fix" them
if it shifts the burden of reproducing the old behaviour on another part
of our code.
> The init functions (that internally call the python TLS apis) could
> simply do a TLS get explicitly themselves, to make it explicit and
> clear that they _want_ to use any pre-existing tls value.
Granted.
> Of course, that won't fix _this_ problem (which is that the main
> thread's tls value gets inherited on fork). The right way to do that
> is to explicitly clearthe main thread's TLS value after fork...
The main thread is fine, actually, it's the other (disappeared) threads
which cause this problem when the same TID is re-used. |
|