<div dir="ltr">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 practice.<br>
<br>On Monday, August 18, 2014, Michi Henning <<a href="mailto:michi@triodia.com" target="_blank">michi@triodia.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi Thomas,<br>
<br>
thanks for the quick answer!<br>
<br>
> 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.<br>


>  zmq::msg_t::close() should not create a race as it relies on the atomic refcount dropping to zero before freeing the heap block.<br>
><br>
> 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.<br>
<br>
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.<br>
<br>
Cheers,<br>
<br>
Michi.<br>
_______________________________________________<br>
zeromq-dev mailing list<br>
<a>zeromq-dev@lists.zeromq.org</a><br>
<a href="http://lists.zeromq.org/mailman/listinfo/zeromq-dev" target="_blank">http://lists.zeromq.org/mailman/listinfo/zeromq-dev</a><br>
</blockquote>
</div>