Hi Bjorn, I agree with your feedback and think it's worthwhile splitting it out into message passing through a lazy initialized socket + inproc transport. It's trivial to pass pointers as messages as well. Traveling today and tomorrow but will create a defect @ JIRA and a patch from the other side for you to review. Might help to get rid of the va_args cruft also. Sounds like a plan ? Anyone else have any further input ?
- Lourens On Tue, Aug 14, 2012 at 2:19 PM, Bjorn Reese <[email protected]>wrote: > Any comments? > > On 2012-08-05 14:37, Lourens Naudé wrote: > > Hi Bjorn, > > > > Great feedback - digesting and will look into it. > > > > - Lourens > > > > On Sun, Aug 5, 2012 at 12:48 PM, Bjorn Reese <[email protected] > > <mailto:[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] <mailto:[email protected]> > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > > > _______________________________________________ > > 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 >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
