[zeromq-dev] 3.x zmq_msg_t change proposal
Chuck Remes
cremes.devlist at mac.com
Thu Oct 27 20:41:25 CEST 2011
On Oct 27, 2011, at 12:58 PM, Chuck Remes wrote:
> e.g. int zmq_msg_flagmatch(zmq_msg_t *msg, unsigned long flags);
In another thread ("Behavior of Labels, Identities, and Socket Types in 3.0"), a similar issue was raised. I had a quick chat with Greg on irc and we refined the proposal to be more C-like.
int zmq_msg_flags(zmq_msg_t *msg);
This function would return an integer with the appropriate bits set for RCVMORE, RCVLABEL, etc. Callers could do explicit tests against these bits like a lot of idiomatic C code. Higher-level APIs that wrap this could provide specific method calls to test for each flag individually.
So the earlier code example would now look a tiny bit different.
int flags;
zmq_msg_t *part;
do {
part = malloc (sizeof(zmq_msg_t);
assert (zmq_msg_init (part) == 0);
assert (zmq_recvmsg (socket, part, 0) != -1);
flags = zmq_msg_flags(part);
if (flags & ZMQ_RCVLABEL)
fprintf (stderr, "label part");
else
fprintf (stderr, "body part");
zmq_msg_close (&part);
} while (flags & RCVMORE);
That is very C-like. Wrapping that up in Ruby (or another higher level lang) could make for a simple and pretty API for things like Message#more?, Message#label?, etc.
There's a possibility that this API would be too low-level for some folks. It would require C users to write macros:
#define TEST_ZMQ_MSG_MORE(flags) (flags & ZMQ_RCMORE)
Adding a slightly redundant function could eliminate that macro.
int zmq_msg_flag(zmq_msg_t *msg, unsigned int flag)
That would return 0/1 for the specific flag.
Thoughts?
cr
More information about the zeromq-dev
mailing list