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 ncoghlan
Recipients amaury.forgeotdarc, anacrolix, docs@python, ncoghlan, nikratio, swapnil, verigak
Date 2010-09-18.02:20:35
SpamBayes Score 8.687196e-08
Marked as misclassified No
Message-id <1284776438.15.0.270829513259.issue6627@psf.upfronthosting.co.za>
In-reply-to
Content
The suggestion in http://bugs.python.org/issue6627#msg116722 is a good one.

This a case where the user may legitimately not realise that threading.local is stored in the *temporary* state created by ctypes rather than in something more persistent inside the interpreter.

Since the ctypes state is per callback, it won't persist across calls, even when they're made from the same thread.

Suggested wording:
"""Note that if the callback function is called in a new thread that has been created outside of Python's control (i.e., by the foreign code that calls the callback), ctypes creates a new dummy Python thread on every invocation, including recreation of the thread local storage area. While this is correct for most purposes, it does mean that values stored with `threading.local` will *not* survive across different callbacks, even when those calls are made from the same C thread."""
History
Date User Action Args
2010-09-18 02:20:38ncoghlansetrecipients: + ncoghlan, amaury.forgeotdarc, nikratio, verigak, swapnil, anacrolix, docs@python
2010-09-18 02:20:38ncoghlansetmessageid: <1284776438.15.0.270829513259.issue6627@psf.upfronthosting.co.za>
2010-09-18 02:20:36ncoghlanlinkissue6627 messages
2010-09-18 02:20:35ncoghlancreate