[zeromq-dev] Event callback questions

Bjorn Reese breese at mail1.stofanet.dk
Sun Aug 5 13:48:08 CEST 2012


The documentation on zmq_ctx_set_monitor() states that one should "be
careful with what you're doing in the callback function as excess time
spent in the handle will block the socket's application thread". This
does not appear to be fully correct.

My investigation shows that the callback function can either be called
by the application thread, e.g. for ZMQ_EVENT_LISTENING, or from a
context thread, e.g. for ZMQ_EVENT_CONNECTED.

It may be tempting for users to call zmq_connect() from the callback
when we receive ZMQ_EVENT_DISCONNECTED, but this may deadlock as the
event is called from the context thread. It might therefore be a
good idea to insert a caveat in the documentation that the callback
function should not call zmq functions.

Alternative, we could construct a different callback mechanism that
has a clear separation between application and library threads. Instead
of a callback, we could create a monitor socket for the context, that
is, an inproc socket to deliver the events.

I know that this may sound like overengineering, but in my experience
errors often occur when we use callbacks in a multithreaded program.

Furthermore, the ZMQ_EVENT_* macros are given values that are a
multiple of 2. Does this mean that the "event" parameter of the
callback may contain two or more events in the same call? If not,
why aren't the ZMQ_EVENT_* values simply consecutive numbers?

Oh, and while I am at it, why is the "event" parameter an "int"
rather than an "unsigned int"?



More information about the zeromq-dev mailing list