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