[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