[zeromq-dev] Zero-copy message API

Martin Sustrik sustrik at 250bpm.com
Sun Apr 3 11:31:54 CEST 2011


Hi Pieter,

> One thing that seems to consistently trip up users is the zero-copy
> message API, and the way it's presented. That is, reading the docs,
> there's no hint that zmq_msg_init_data() is much harder to use
> properly than zmq_msg_init_size().

Yes. Agreed.

> For the 3.0 API, it could be neat to slice these apart and make it
> clearer that there is a simple way for 90% of apps, and a complex way
> for 10%.
>
> For example, zmq_msg_init() might take a size argument, and merge the
> functionality of zmq_msg_init_size(), and then we could rename
> init_data to zmq_msg_init_zerocopy().

As for merging zmq_msg_init with zmq_msg_init_size the only downside is 
that it makes receiving a message look a bit strange:

zmq_msg_t msg;
size_t size = 0;
zmq_msg_init_size (&msg, size); // instead of zmq_msg_init (&msg);
zmq_recvmsg (s, &msg, 0);

As for me, I would vote on the proposal -0.1 :)
Opinion, anyone?

As for renaming zmq_msg_data to zmq_msg_zerocopy, I would say that the 
actual semantics of the command is not "zero copy" but "user defined 
allocator". This has to do with the custom allocation on recv() side (as 
discussed recently on the list) as well. Let's see where the discussion 
will head.

Martin



More information about the zeromq-dev mailing list