global interpreter lock

Mike Meyer mwm at
Mon Aug 22 20:19:48 CEST 2005

Paul Rubin <> writes:
> Mike Meyer <mwm at> writes:
>> Even simpler to program in is the model used by Erlang. It's more CSP
>> than threading, though, as it doesn't have shared memory as part of
>> the model. But if you can use the simpler model to solve your problem
>> - you probably should.
> Well, ok, the Python equivalent would be wrapping every shareable
> object in its own thread, that communicates with other threads through
> Queues.  This is how some Pythonistas suggest writing practically all
> multi-threaded Python code.  It does a reasonable job of avoiding
> synchronization headaches and it's not that hard to code that way.

This sort of feels like writing your while loops/etc. with if and
goto. Sure, they really are that at the hardware level, but you'd like
the constructs you work with to be at a higher level. It's not really
that bad, because Queue is a higher level construct, but it's still
not quite not as good as it could be.

> But I think to do it on Erlang's scale, Python needs user-level
> microthreads and not just OS threads.  Maybe Python 3000 can add some
> language support, though an opportunity was missed when Python's
> generator syntax got defined the way it did.

I'm not sure we need to go as far as Erlang does. On the other hand,
I'm also not sure we can get a "much better" threading model without
language support of some kind. Threading and Queues are all well and
good, but they still leave the programmer handling primitive threading

Mike Meyer <mwm at>
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

More information about the Python-list mailing list