Guido van Rossum wrote:
> Aahz:
>>
>> We need thread-local storage, anyway. When I'm a little farther into my
>> work on Decimal, I'm going to take a hard look at this because context
>> needs to be global on a per-thread basis...
>
> In the C API, use PyThreadState_GetDict(): it returns a per-thread
> dictionary. The convention is that you pick a key unique to your
> extension module (e.g. your full extension module name) and then store
> your per-thread data under this key.
>
> In Python, you can store instance variables on the current thread
> object -- use threading.currentThread() to access it.
It's not quite that simple, particularly if one is writing Python code
that permits use of the thread module instead of requiring threading.
But what I was really referring to was the annoyance of having every
method call pull in the thread-local information. Seems to me that
there ought to be some way of making it happen magically.
Another issue is the problem of inheriting thread-local values when
creating a new thread. That almost certainly requires a callback inside
the thread creation machinery.
Because I haven't thought much about this, there are probably other
issues I don't know about....
--
--- Aahz (@pobox.com)
Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista
I don't really mind a person having the last whine, but I do mind someone
else having the last self-righteous whine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4