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.
On Monday, August 18, 2014, Michi Henning <mi...@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. > > Cheers, > > Michi. > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
