[zeromq-dev] Extending zmq_msg_t API

[Thomas Rodgers]

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 <ph at imatix.com> wrote:

> On Thu, Jul 10, 2014 at 12:00 AM, Thomas Rodgers <rodgert at twrodgers.com>
> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140729/f9d4e1e7/attachment.htm>