[zeromq-dev] Edge-triggered polling vs Level-triggered. Which one ZMQ is using? Why?

artemv.zmq artemv.zmq at gmail.com
Fri Aug 15 12:22:53 CEST 2014


hi Goswin

You mentioned:

>With a level trigger you can poll() and then consume one message from
>every socket that has input available. Rince and repeat. No socket can
>starve any other.

Why polling every time and do 1-poller-tick/1-msg-handling?  I usually do
with zmq' poller like following:

...

poller.poll();

...

if (poller.pollin(0)) {
  for (;;) {
    frames = socket.recv(DONTWAIT);
    if (frames == null)
      break;

    ... // process frames here.
  }
}

...

I.e.  gobble messages until I can consume them.


BR
-artemv




2014-08-07 17:05 GMT+03:00 Goswin von Brederlow <goswin-v-b at web.de>:

> On Wed, Jul 30, 2014 at 12:32:03PM -0700, Michel Pelletier wrote:
> > On Mon, Jul 21, 2014 at 11:23 AM, Goswin von Brederlow <
> goswin-v-b at web.de>
> > wrote:
> >
> > > On Mon, Jul 14, 2014 at 08:42:14AM -0700, Michel Pelletier wrote:
> > >
> >
> >
> > > I think it is a big issue.
> > >
> > > On read a level trigger is better because when you didn't consume all
> > > input then the next zmq_poll() should not block. It's too easy to
> > > accidentally run into this. Further you actually do want to only
> > > consume some input from each socket and then poll again. The reason
> > > for that is so that you can round-robin all sockets fairly, e.g.
> > > consume one message from each socket and then poll again. If you
> > > instead consume as much as possible from every socket then one socket
> > > can be flooded with messages and starve other sockets. So level
> > > trigger on read is a must for me.
> > >
> >
> > By the time you are calling poll the flood has already occurred, the data
> > has arrived locally and is in memory.  The polling strategy isn't a form
> of
>
> The RCVHWM will put a stop into the flow there. So you don't get a
> total flood. You can still get a bad ratio of messages handled between
> sockets, 1:1000 with the default HWM.
>
> > flow control.  At some point something has to block or drop when you
> don't
> > consume the data that has arrived whether in one edge triggered call or
> > many level triggered calls.  If you're worried about flooding then credit
> > based flow control is the way to go.
> >
> > -Michel
>
> No. Credit based flow control is something different.
>
> This is about simplicity.
>
> With a level trigger you can poll() and then consume one message from
> every socket that has input available. Rince and repeat. No socket can
> starve any other.
>
> With edge trigger you poll(), consume one message from every socket
> that has input available and then you have a problem. You can't simply
> poll again. You have to remember the sockets from the last poll call
> and merge them with the result of the next one since sockets that had
> messages the last time might or might not appear again if they have
> more input now. That is not just a lot harder to put into words but
> also much harder to implement.
>
> MfG
>         Goswin
> _______________________________________________
> 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/20140815/de6fbb2c/attachment.html>


More information about the zeromq-dev mailing list