(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 successful. 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? _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
