[zeromq-dev] Event callback questions

[Lourens Naudé]

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>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
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120805/4ac38696/attachment.htm>