It sounds like a valid problem, and the simplest answer seems to be a zmq_msg_get() constant.
On Wed, Jul 9, 2014 at 12:21 PM, Thomas Rodgers <rodg...@twrodgers.com> wrote: > zmq_msg_get() could be extended to give either the refcount or an indicator > on whether a message was share; based on other refcounted designs I'm > hesitant to promote surfacing the actual count. Similarly, zmq_msg_set() > could allow 'unsharing' by adding a ZMQ_SHARED property #define and setting > it's value to 0 (no effect on non-shared messages). > > So the only API surface area change is an additional message property. This > seems the cleanest to me. > > > On Wednesday, July 9, 2014, Goswin von Brederlow <goswin-...@web.de> wrote: >> >> On Tue, Jul 08, 2014 at 10:42:41AM -0500, Thomas Rodgers wrote: >> > tl;dr; Is there any objection to adding some sort of accessor to the API >> > to >> > determine if a given zmq_msg_t is_shared()? >> > >> > Background/Rationale: >> > >> > Something I encountered while writing a "high level" C++ wrapper for >> > zmq_msg_t and it's API is the following set of behaviors - >> > >> > zmq_msg_init(&msg_vsm, 20); >> > >> > Results in a type_vsm message, the body of which is held entirely within >> > the space allocated to zmq_msg_t >> > >> > zmq_msg_init(&msg_lmsg, 1024); >> > >> > Results in a type_lmsg message, the body is held as a reference to a >> > block >> > of size bytes. >> > >> > memcpy(zmq_msg_data(&msg_vsm), "VSM", 3); >> > memcpy(zmq_msg_data(&msg_lmsg), "LMSG", 4); >> > >> > So far so good. Now copy - >> > >> > zmq_msg_copy(&msg_vsm2, &msg_vsm); >> > zmq_msg_copy(&msg_lmsg2, &msg_lmsg); >> > >> > Now change contents - >> > >> > memcpy(zmq_msg_data(&msg_vsm2), "vsm", 3); >> > memcpy(zmq_msg_data(&msg_lmsg2), "lmsg", 4); >> > >> > assert(memcmp(&msg_vsm, &msg_vsm2, 3) != 0); // ok >> > assert(memcmp(&msg_lmsg, &msg_lmsg2, 4) != 0); // fail >> > >> > This happens by design (lmsg's are refcounted on copy, not deep copied). >> > But it results in a situation where a zmq_msg_t is sometimes a Value and >> > sometimes a Reference. This could lead to astonishment for the unwary. >> > >> > >From the perspective of a wrapper (particularly one that takes a strong >> > stand on value semantics and local reasoning), this behavior is ungood. >> > So >> > my options are deep copy always or implement copy-on-write. >> > >> > For efficiency I prefer the latter approach in the case of type_lmsg >> > messages. I have implemented the copy-on-write logic through a horrible >> > brittle hack that examines the last byte of zmq_msg_t. I would prefer a >> > less brittle solution. >> >> "lmsg's are refcounted on copy" Can't you access the refcount? >> Or is that the API call you want to add? >> >> Maybe instead of is_shared() an unshare() call would be more usefull, >> which would copy the message payload if it is shared. Or both? >> >> MfG >> Goswin >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
