[zeromq-dev] zmq_monitor

[Lourens Naudé]

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 <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
> 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
> 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/20120912/7a8c7ad1/attachment.htm>