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