[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