[zeromq-dev] Message deallocating after sending
Martin Sustrik
sustrik at fastmq.com
Thu Apr 30 09:50:47 CEST 2009
Hi Ayman,
> After sending a message using send(..) the message should be
> deallocated, as documented in api_thread.hpp(see the code snip bellow).
>
> If I resend the same message once more the buffer is sent but the
> arrived message size is 0.
>
> There is the method present() which requires to call flush(), which I
> could use.
>
> But, I don’t know if this is the indented behaviour for send(), since in
> this case
>
> you are sending “useless” data.
>
> The same behaviour is noticed for v0.5 and v0.6
Yes, this behaviour is intended. The rationale is to preserve zero-copy
semantics and avoid reference counting on message if possible.
The reasoning goes like this:
1. The message cannot be copied so that user keeps the original data and
0MQ pushes the copy to the network in the background - that would
violate the zero-copy requirement.
2. Optionally, the data can be reference counted (one reference from the
user, other one from 0MQ background I/O thread), however, reference
counting requires atomic ops that require CPU cache coherency to kick
in. Synchronising the caches can be slow and should be avoided if at all
possible.
3. To address these issues, we move the ownership of data buffer from
the user to the background I/O thread. There's neither copy not atomic
ops involved in the process, making it *very* fast.
Anyway, if what you need is to preserve the original data after sending
the message, use copy_to function:
message_t msg;
// Fill the message data in here.
message_t tmp;
msg.copy_to (&tmp)
api->send (eid, tmp);
// At this point tmp is empty but msg still contains the original data.
Note that the copy operation increases the reference count rather than
copy the data, so avoid modifying the data once you've made a copy.
Hope this helps.
Martin
More information about the zeromq-dev
mailing list