[zeromq-dev] libzmq and helgrind
rodgert at twrodgers.com
Tue Aug 19 04:53:54 CEST 2014
Hmmmm, I just ran this on my *nix box (Ubuntu 14.04, gcc4.8) with helgrind
and I get no races in zmq::msg_t::close() reported, nor do I see anything
in the implementation of zmq::msg_t::close() that's likely racey in
On Monday, August 18, 2014, Michi Henning <michi at triodia.com> wrote:
> Hi Thomas,
> thanks for the quick answer!
> > If the message size exceeds the 'vsm' message length limit, it becomes
> an 'lmsg'. This type is indeed heap allocated, and when the enclosing
> message type is copied, the copies share the reference to the underlying
> heap allocation (and any potential data races that come along with that).
> The lifetime is controlled by an atomic refcount.
> > zmq::msg_t::close() should not create a race as it relies on the atomic
> refcount dropping to zero before freeing the heap block.
> > Access to the actual message data() could potentially create a data
> race, but the receiving side should never have access to a message that is
> still being written by a background thread.
> OK, so that sounds like the races on data() and memcpy() are bogus. What
> about the close() race though? I wasn't expecting to see that one.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev