Parallelization on muli-CPU hardware?

Alex Martelli aleaxit at
Thu Oct 7 19:56:10 CEST 2004

Aahz <aahz at> wrote:

> In article <1glatga.8upk9brifr2qN%aleaxit at>,
> Alex Martelli <aleaxit at> wrote:
> >Aahz <aahz at> wrote:
> >>
> >> The problem is that CPython doesn't have thread-local storage.
> >
> >In 2.4 it does -- see threading.local documentation at
> ><> (and
> >even better, the docstring of the new _threading_local module).
> IIUC, that's not thread-local storage in the sense that I'm using the
> term (and which I believe is standard usage).  Values created with
> thread-local storage module are still allocated on the heap, and it's
> still possible to use introspection to access thread-local data in
> another thread.

Is it...?  Maybe I'm missing something...:

import threading

made_in_main = threading.local() = 23
def f():
    print 'foo in made_in_main is', getattr(made_in_main, 'foo', None)

print 'in main thread:',
t = threading.Thread(target=f)
print 'in subthread:',
print 'back in main thread:',

What I see is:

kallisti:~/cb/little_neat_things alex$ python2.4 
in main thread: foo in made_in_main is 23
in subthread: foo in made_in_main is None
back in main thread: foo in made_in_main is 23

so how does a subthread introspect to 'break the rules'...?  (preferably
in a platform-independent way rather than by taking advantage of quirks
of implementation or one or another platform)

> Don't get me wrong; I think it's a brilliant addition to Python.
> Unfortunately, it doesn't help with the real issues with making the
> Python core free-threaded (or anything more fine-grained than the GIL).

I'm not claiming it does, mind you!  It's just that it DOES seem to me
to be a "true" implementation of the "thread-specific storage" design
pattern, and I don't know of any distinction between that DP and the
synonym "thread-local storage" (Schmidt et al used both interchangeably,
if I'm not mistaken).


More information about the Python-list mailing list