[zeromq-dev] zmq_monitor

[MinRK]

Hello,

We've been investigating <https://github.com/zeromq/pyzmq/pull/251> 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.

Can someone explain why the monitor is per-context and not per-socket?  I
saw on the list<http://lists.zeromq.org/pipermail/zeromq-dev/2012-May/017197.html>
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?

Who is using this feature, and how are they using it?  Do people really
prefer only being able to monitor all sockets or none, or does a per-socket
monitor callback make more sense, as the original implementation intended?

If a change is desirable, what are the issues with libzmq releases and
compatibility?  There haven't been any actual releases yet with this
feature, and I have no idea how popular/critical the current behavior is
for beta users, so I don't know where to start with what would be
problematic or appropriate. But after our first stab at supporting it in
pyzmq, it really seems like the current design is not the right way to go.

-MinRK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120912/7b8133a3/attachment.htm>