> On Aug 24, 2018, at 4:59 AM, Luca Boccassi <[email protected]> wrote: > > There's already event monitoring for that
Yes, and I’m already using event monitoring, but with some nervousness — because of the serious consequences if something goes wrong with event monitoring (i.e., the process freezes solid, and zmq calls hang forever), and also because I don’t have a good feel for what overhead socket monitoring adds. The approach I’m using currently is to spin up a separate thread to poll the monitor socket(s), and to simply log a message when a significant event occurs on a socket. Socket monitoring can be enabled and disabled at runtime, and so is completely optional. I’ve been reluctant to make it an integral part of the application because of the concerns I mentioned earlier. On a practical level, using event monitoring to control application state is not a great approach, given that delivery of socket events is asynchronous with respect to the actual events, which opens up all sorts of holes and race conditions, e,g,: "Warning: there is no guarantee that the FD is still valid by the time your code receives this event." To me it seems simpler and safer to have socket events delivered in-line with the data itself.
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
