[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