this seems like an unusual case to force a library change. On Dec 13, 2011, at 7:33 PM, 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). > > 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 ------------------ Andrew Hume (best -> Telework) +1 623-551-2845 and...@research.att.com (Work) +1 973-236-2014 AT&T Labs - Research; member of USENIX and LOPSA
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
