Reopening this - I added zmq_msg_get() support for ZMQ_SHARED to return the state of the shared flag. This works well enough, but you essentially run into the same problem when the message is constructed from "const" data, resulting in a cmsg type message. It is effectively "potentially shared" on copy.
The question is, should I extend the getter for ZMQ_SHARED to return true in the case of type_cmsg, or add a separate operation? Thanks, Tom. On Wed, Jul 9, 2014 at 5:25 PM, Pieter Hintjens <[email protected]> wrote: > On Thu, Jul 10, 2014 at 12:00 AM, Thomas Rodgers <[email protected]> > wrote: > > > 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. > > Doesn't look nice IMO. If you actually need to solve this problem, an > explicit method like zmq_msg_deref() would be cleaner. However since > it's not solving a real problem, you shouldn't make it. > > > 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. > > Yes, that's nice. > > -Pieter > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
