[zeromq-dev] Race condition in cppzmq zmq::socket_t::close() / cppzmq tag?

Luca Boccassi luca.boccassi at gmail.com
Thu Dec 15 10:32:11 CET 2016


Note that as the documentation also says you must close the sockets before
destroying the context, not after

On Dec 15, 2016 07:40, "Eric Pederson" <ericacm at gmail.com> wrote:

> Right - normally I would not access a socket from two threads.
>
> The scenario is unit testing. We have a class that encapsulates a set of
> sockets and also a thread with a loop that polls the sockets.
>
> When the test is over, I do the following to clean it up:  close the
> context so the poll blocked in the thread throws an exception with ETERM.
> I close the sockets after catching the exception and returning from the
> thread.  The destructor joins the thread so the object doesn't get
> destroyed before the thread is finished.  Then the destructor continues and
> the socket members get destroyed.  All this works fine normally because the
> sockets are usually closed before the socket destructor runs.  But
> sometimes the closing in the thread would race with the destruction.
>
> I found that it is because some tests were not joining the thread but
> instead detaching it.  So it looks like we have a nice deterministic
> shutdown process finally.
>
> Thanks,
>
>
> That could only happen if the same socket was used or managed from multiple
>> threads. As the documentation clearly states, sockets are intentionally
>> not
>> thread safe and must not be used from multiple threads.
>
>
> -- Eric
>
> On Wed, Dec 14, 2016 at 2:24 AM, Eric Pederson <ericacm at gmail.com> wrote:
>
>> I ran into a race condition in zmq::socket_t::close() in cppzmq:
>>
>>
>> *inline void *close() ZMQ_NOTHROW
>> {
>>     *if*(ptr == NULL)
>>
>> *// already closed        **return *;
>>
>> *// Someone can sneak in here and close the socket*
>>     *int *rc = zmq_close (ptr);
>>     ZMQ_ASSERT (rc == 0);
>>     ptr = 0 ;
>> }
>>
>> I worked around it using compare-and-swap to atomically check if it's
>> already closed. Does that kind of fix sound reasonable for
>> zmq::socket_t::close()?
>>
>>
>> Also I wanted to follow up on my previous question about tagging cppzmq.
>> I think that conversation got lost in the list shutdown that happened
>> recently.  Does it make sense to regularly tag the cppzmq repo with the
>> corresponding ZeroMQ version?
>>
>> Thanks,
>>
>> -- Eric
>>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20161215/1b4c0132/attachment.htm>


More information about the zeromq-dev mailing list