> On Aug 24, 2018, at 5:02 AM, Luca Boccassi wrote:
>
> This is a very old issue that has its roots in some of the commands
> needing to be processed in the application thread. The solution is to
> refactor and move them to the I/O thread instead.
>
> But it's of course much easier said than
> On Aug 24, 2018, at 4:59 AM, Luca Boccassi wrote:
>
> There's already event monitoring for that
Yes, and I’m already using event monitoring, but with some nervousness —
because of the serious consequences if something goes wrong with event
monitoring (i.e., the process freezes solid, and
On Thu, 2018-08-23 at 16:33 -0400, Bill Torpey wrote:
> Thanks, James!
>
> That’s a very informative thread. This whole business with
> process_commands and the way ZeroMQ handles resources seems to be a
> classic case of a “leaky abstraction”: i.e., it all “just works” —
> except when it
On Thu, 2018-08-23 at 16:52 -0400, Bill Torpey wrote:
> One more thing…
>
> I wonder if it is at all feasible to expand the definition of the
> events that zmq_poll returns to include connection-related events, in
> addition to just I/O events.
>
> It could be very useful to get notified not
Hi Bill,
Could you use the socket monitor and poll the output socket of that for
connection events?
http://api.zeromq.org/4-2:zmq-socket-monitor
Also I love the idea of a middle ground guide to zeromq guts, I have read
the whitepaper you mentioned in the past but its limited. Also things like
One more thing…
I wonder if it is at all feasible to expand the definition of the events that
zmq_poll returns to include connection-related events, in addition to just I/O
events.
It could be very useful to get notified not only if there is data to be
received on a socket, but also if a
Thanks, James!
That’s a very informative thread. This whole business with process_commands
and the way ZeroMQ handles resources seems to be a classic case of a “leaky
abstraction”: i.e., it all “just works” — except when it doesn’t.
In my particular case, this problem turns out to be a bit of
As a side note, having some method to call process_commands while idle
would also fix the memory usage issues encountered when using ZMQ_CONFLATE
and not reading from the socket.
https://github.com/zeromq/libzmq/issues/3171
I added documentaion to periodically call getsockopt with ZMQ_EVENTS but
I’m posting this here since not everyone on the list will necessarily see the
Github issue, and I’m interested in getting as much feedback as possible.
The issue in question ( https://github.com/zeromq/libzmq/issues/3186 ) has to
do with finding a good way to trigger process_commands on
