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 kristjan.jonsson
Recipients bquinlan, dmalcolm, jnoller, kristjan.jonsson, lukasz.langa, neologix, pitrou, sandro.tosi, ysj.ray
Date 2011-04-27.14:40:52
SpamBayes Score 6.0702826e-07
Marked as misclassified No
Message-id <1303915253.47.0.0442754855539.issue10517@psf.upfronthosting.co.za>
In-reply-to
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.

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.

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...
History
Date User Action Args
2011-04-27 14:40:53kristjan.jonssonsetrecipients: + kristjan.jonsson, bquinlan, pitrou, jnoller, dmalcolm, sandro.tosi, ysj.ray, neologix, lukasz.langa
2011-04-27 14:40:53kristjan.jonssonsetmessageid: <1303915253.47.0.0442754855539.issue10517@psf.upfronthosting.co.za>
2011-04-27 14:40:52kristjan.jonssonlinkissue10517 messages
2011-04-27 14:40:52kristjan.jonssoncreate