[zeromq-dev] Extending zmq_msg_t API

[Thomas Rodgers]

Pull req submitted.

Thanks,
Tom.


On Tue, Jul 29, 2014 at 1:06 PM, Pieter Hintjens <ph at imatix.com> wrote:

> Since it's a single semantic ("you do not own this message") one name is
> better.
>
> On Tue, Jul 29, 2014 at 4:30 PM, Thomas Rodgers <rodgert at twrodgers.com>
> wrote:
> > 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
> >
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> _______________________________________________
> 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/ad161d33/attachment.htm>