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
