Hi Bjorn, Great feedback - digesting and will look into it.
- Lourens On Sun, Aug 5, 2012 at 12:48 PM, Bjorn Reese <[email protected]>wrote: > 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 >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
