[zeromq-dev] PUSH/PULL over inproc and nonblocking sends

Peter Bourgon zeromq.peter at bourgon.org
Wed Aug 3 16:15:08 CEST 2011

(https://zeromq.jira.com/browse/LIBZMQ-237 spawns this discussion thread.)

The Situation:
A task distributor/worker threadpool, implemented with a PUSH/PULL
pair over the inproc transport. One thread binds to the PUSH side, and
sends with ZMQ_NOBLOCK. N threads bind to the PULL side, and make
blocking receives.

The Problem:
No matter what I set the PUSH HWM, the send will never error with
EAGAIN, even if the receivers sleep(100) on every recv. If I change to
a TCP transport, I get what I expect: HWM=1 on the PUSH side quickly
results in EAGAIN errors.

The Official Explanation:
Because no HWM is set on the PULL side, it is interpreted as infinite
HWM (for the inproc transport, at least). Therefore, every send is

My Response:
I agree that it doesn't make sense to set HWM on the PULL side. In the
[common] case of multiple PULL receivers, it's undesirable to have
different HWM-triggered behavior purely as a function of which
receiver the PUSH/PULL socket has decided to choose (via its
scheduling algorithm). I therefore agree that PULL HWMs are, and must
be, undefined. But I don't agree that an undefined PULL HWM should be
interpreted as infinite. If anything, it should be interpreted as 1,
as I can't think of any [practical] use case where the PULL recv would
be non-blocking. In short, swapping inproc for tcp should not result
in a change of behavior, in this instance.

Comments? Counter-arguments?

More information about the zeromq-dev mailing list