[zeromq-dev] Raw proposals for 3.0 APIs

Martin Sustrik sustrik at 250bpm.com
Mon Mar 21 15:57:15 CET 2011

On 03/21/2011 01:13 PM, Pieter Hintjens wrote:

> Anyhow, this is straw for beating up, so please do discuss.

Well, I think the subsequent email about layering non-POSIX APIs on top 
of POSIX APIs makes this discussion irrelevant, however, given that the 
reationale behind zmq_msg_t design isn't documented anywhere, let me 
briefly explain why sending and receiving functions use message objects 
(zmq_msg_t) instead of raw buffers (void*):

1. User should be able to send buffer -- without copying it -- that was 
allocated by application-specific allocation mechanism. Thus, the 
message contains pointer to deallocation function rather then relying on 
hard-wired allocation mechanism such as malloc/free.

2. When using inproc:// transport, message is never copied. Thus, the 
buffer sent in one thread, will be received in the other thread and 
should be deallocated there. Thus, when doing recv() we should get 
pointer to deallocation function alongside the buffer itself.

3. For very small messages (VSMs) it's cheaper to copy the message than 
keep it on heap. These messages thus have no associated buffer and the 
data are stored directly in the zmq_msg_t structure -- presumably on the 
stack. This has huge impact on performance as it almost entirely avoids 
need to do allocations/deallocations.

4. zmq_msg_t supports reference counting. Thus, if a message is 
published to many different TCP connections, all the sending threads 
access the same buffer rather then copying the buffers. Same trick can 
be used by user using zmq_msg_copy function:

     zmq_msg_copy (copy_of_msg, msg);
     zmq_send (sock1, msg);
     zmq_send (sock2, copy_of_msg);


More information about the zeromq-dev mailing list