I will work up a patch over the next few days. Any opinion on a corresponding zmq_msg_set() constant where a value of 0, forces (only) a shared message to be deep copied "under the hood" and clears the shared flag bit? It is not strictly necessary for my purposes, any other value than zero is nonsense.
Not to cross the streams too much, but digging through msg.cpp it seems there a few cases with message accessors which return EINVAL that also to fall into the same category of incorrect usage that you recently added "militant" asserts for in socket options. On Wed, Jul 9, 2014 at 2:26 PM, Pieter Hintjens <p...@imatix.com> wrote: > 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 >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
