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.
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
