Hi Guys, There's another thread that touch on some of these points as well. I agree that a callback doesn't make much sense for higher level languages. It could be replaced with an inproc:// PUB socket, with event metadata being multipart messages published to that socket. I can take a stab @ this soon. Thoughts ?
- Lourens On Wed, Sep 12, 2012 at 11:16 PM, Paul Colomiets <[email protected]>wrote: > Hi Benjamin, > > On Thu, Sep 13, 2012 at 12:48 AM, MinRK <[email protected]> wrote: > > Hello, > > > > We've been investigating adding support for the experimental new monitor > > functionality in pyzmq, and I have some questions. > > > > The callback is per-context, which makes no sense to me. If I wanted to > > monitor socket events on one socket out of one hundred, I have only two > > choices: make the callback aware of which socket(s) it cares about, and > try > > to make minimize the disruption when called on the 99 sockets I don't > care > > about (troublesome in Python, as acquiring the GIL from the io_thread is > > already problematic), or register monitored sockets with one Context, and > > non-monitored sockets with another. > > > > 1. All the conditions, that trigger monitor callback are not at hot places. > 2. They are not intended for business logic, so the only thing you should > probably do is find a name for the socket and log the message > > > Can someone explain why the monitor is per-context and not per-socket? I > > saw on the list that it was added to the Context for a cleaner interface > > than cramming it into setsockopt. Is there any reason that > > zmq_ctx_set_monitor is preferable to zmq_socket_set_monitor, which would > > solve the exact same problem, without a fundamental change in how it is > > meant to work? > > > > Not that I support this implementation, but it's ok for me. > > For python implementation, I think you should provide something along > the options: > > 1. Write monitoring message to another socket (possibly inproc) > > 2. Write message to the specified logger directly (as you need to hold > GIL at the moment of writing, and python logging is quite heavyweight, > this option may be implemented in another thread and inproc socket) > > 3. Collect number of occurrences of each of the event in the socket > object, so it can be periodically inspected by main loop and sent to > statistics collection software > > In my opinion it's wrong to provide callback interface for ZMQ_MONITOR > in scripting languages. > > Thoughts? > > -- > Paul > _______________________________________________ > 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
