[docs] [issue6627] threading.local() does not work with C-created threads

Nick Coghlan report at bugs.python.org
Tue Sep 21 15:03:24 CEST 2010


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On Tue, Sep 21, 2010 at 2:39 PM, Swapnil Talekar <report at bugs.python.org> wrote:
> Swapnil Talekar <swapnil.st at gmail.com> added the comment:
> Nick, the last statement,
> "While this is correct for most purposes, it does mean that..."
> can be simplified to,
> "It means...".
> I had to read it several times before I realized, there is no "not" after "does" :)

The shorter version doesn't mean the same thing though - the ctypes
arrangement *really is* correct for most purposes. The only issue is
that threading.local won't persist, since the storage is blown away as
soon as the callback returns.

> BTW, since this particular arrangement of having a temporary thread state during the callback is particularly useful for ctypes (I cannot imagine any other usecase) and also it sort-of breaks things, a potential feature request could be to have consistent thread state during the lifetime of a C thread. I don't have much idea how to do that or whether it is even possible? Would anyone like to give a thought?

There's no easy way to make the thread state persist between calls, as
ctypes needs to destroy the thread state it creates at some point to
avoid a memory leak. Since it has no way of knowing when the
underlying C thread is no longer in use, it is forced to assume that
every call is going to be the last one from that thread and kill the
thread state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6627>
_______________________________________


More information about the docs mailing list