[zeromq-dev] Multicore Magic

[Joe Holloway]

Hey guys,

>> * Python still has the Global interpreter lock that prevents more than
>> one thread from executing Python code at a time.  This means that
>> thread based concurrency is not an option for Python.  IOW, we can't
>> use multiple threads that talk using OMQ.  So, we have to use
>> processes.  I don't like that, but maybe it is OK...
>
> Well, it's deficiency of Python. Hopefuly Python developers would
> address the issue in the future.
>
> Btw, maybe it would be worth poking them a little by asking about the
> behaviour on python dev mailing list...

Probably preaching to the choir, but the GIL is only a limitation of
the CPython runtime.  There are other (albeit less mature) Python
implementations that are not necessarily affected by the GIL, e.g.
Jython, IronPython, Stackless, PyPy, et al.  Also, there's the Google
sponsored "Unladen Swallow" project that aims to reinvent the CPython
runtime so as to improve performance and remove the GIL.

Presumably, the 0MQ native Python glue could be ported to one of those
other runtimes if necessary.  If your wagon is hitched to CPython,
maybe you can get by with IPC while the Unladen Swallow project
matures and then switch over to an inproc transport later on.