paul at colomiets.name
Thu Sep 13 00:16:58 CEST 2012
On Thu, Sep 13, 2012 at 12:48 AM, MinRK <benjaminrk at gmail.com> wrote:
> 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
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.
More information about the zeromq-dev