[zeromq-dev] Edge-triggered polling vs Level-triggered. Which one ZMQ is using? Why?
Goswin von Brederlow
goswin-v-b at web.de
Thu Aug 7 16:05:11 CEST 2014
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>
> > 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.
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.
More information about the zeromq-dev