[zeromq-dev] Extending zmq_msg_t API

[Thomas Rodgers]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140708/2adddd53/attachment.htm>