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). 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? Does anyone see a problem with this approach? I'm going to experiment with it in a project I am working on but I wanted to throw the idea out there just in case someone with a sharper eye can see a flaw. cr _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
