[zeromq-dev] Extending zmq_msg_t API

[Pieter Hintjens]

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
>