[zeromq-dev] 0MQ 1.0.1 Python Global Interpreter Lock patch?

Aamir M intuitionist at gmail.com
Tue Oct 20 16:23:26 CEST 2009


Hi Martin,

Yes, I submit the code under the MIT License.

Regards,
Aamir

On Tue, Oct 20, 2009 at 6:16 AM, Martin Sustrik <sustrik at fastmq.com> wrote:
> Hi Aamir,
>
>> I am trying to use the 0MQ 1.0.1 Python API to send / recv 0MQ
>> messages in one Python thread while driving a GUI in another Python
>> thread. However, whenever I use the blocking send / recv 0MQ calls,
>> the whole Python process freezes and waits for network I/O (so the GUI
>> becomes non-responsive, etc). It seems that pyzmq.cpp
>> (http://github.com/sustrik/zeromq1/blob/master/libpyzmq/pyzmq.cpp) is
>> not thread friendly. I was able to get around the problem by modifying
>> the pyZMQ_receive and pyZMQ_send functions .... specifically, line 176
>> in pyzmq.cpp reads:
>>
>> sent = self->api_thread->send (exchange, message, block);
>>
>> I replaced this with:
>>
>> Py_BEGIN_ALLOW_THREADS
>> sent = self->api_thread->send (exchange, message, block);
>> Py_END_ALLOW_THREADS
>>
>> Similarly, I changed line 192 to:
>>
>> int queue;
>> Py_BEGIN_ALLOW_THREADS
>> queue = self->api_thread->receive (&message, block);
>> Py_END_ALLOW_THREADS
>>
>>
>> In summary, I just simply the 0MQ C++ blocking calls with the Python
>> macros Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS, which are
>> described in http://docs.python.org/c-api/init.html ... These macros
>> release and reacquire the CPython Global Interpreter Lock.
>>
>>
>> Is this a bug in the 0MQ 1.0.01 library that should be patched? Or is
>> my patch somehow incorrect?
>
> We knew about the problem but we haven't found a suitable solution yet. Your
> fix looks like it should solve the problem. Would you be OK with submitting
> it under MIT license?
>
> Martin
>



More information about the zeromq-dev mailing list