lourens at methodmissing.com
Thu Sep 13 00:29:11 CEST 2012
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.
On Wed, Sep 12, 2012 at 11:16 PM, Paul Colomiets <paul at colomiets.name>wrote:
> Hi Benjamin,
> On Thu, Sep 13, 2012 at 12:48 AM, MinRK <benjaminrk at gmail.com> 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
> > to make minimize the disruption when called on the 99 sockets I don't
> > 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.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev