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);
Martin
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
