[zeromq-dev] Event callback questions

[Lourens Naudé]

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 <breese at mail1.stofanet.dk>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 <breese at mail1.stofanet.dk
> > <mailto:breese at mail1.stofanet.dk>> 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
> >     zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
> >     http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> >
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120814/cddaec99/attachment.htm>