On 12/14/2011 11:33 AM, Chuck Remes wrote: > I have a protocol (like majordomo) that uses message parts to send > some of the same "boilerplate" data on every message. Currently I > allocate a new zmq_msg_t for each of these "frames" and let the > library handle the deallocation, but it occurred to me that this > might not be a good idea. > > What if I allocate the zmq_msg_t once and, before passing it to > zmq_send/zmq_sendmsg, I call zmq_msg_copy on it to increase its > refcount. The library returns another zmq_msg_t to me in the buffer I > gave it but it let's me avoid the memcpy call for the "data" (which > may be a negligible cost for small data but could be significant for > large buffers).
Yes. That would work. You can have a boilerplate message part stored and send it this way: zmq_msg_copy (tmp, boilerplate); zmq_send (tmp); > Now that I have typed this out, it would be nice if I could operate > *directly* on the original zmq_msg_t and avoid the effort of even > creating a destination zmq_msg_to for zmq_msg_copy to replace. What > about a zmq_msg_increment_refcount(zmq_msg_t *src) api call to let me > do this work directly? In theory we can add something like zmq_msg_add_ref() to get that functionality. The question is whether more explicit reference management using separate zmq_msg_t per reference doesn't lead to better coding style. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
