Antoine Pitrou <pit...@free.fr> added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10517> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
