[zeromq-dev] HWM behaviour & blocking

Paul Colomiets paul at colomiets.name
Thu Jun 28 12:50:57 CEST 2012

Hi Justin,

On Thu, Jun 28, 2012 at 8:50 AM, Justin Karneges <justin at affinix.com> wrote:
> On Thursday, May 10, 2012 01:53:48 PM Pieter Hintjens wrote:
>> On Thu, May 10, 2012 at 3:44 PM, Paul Colomiets <paul at colomiets.name> wrote:
>> > Can you be more specific, why setting HWM to 1 is a bad thing? Do you
>> > mean, that it smells bad to set HWM to 1 for reliability? Or do you
>> > think that setting it will have other consequences? (low performance?)
>> it's bad because you're trying to force a synchronous model on an
>> asynchronous system, and doing it at the wrong level. If you really
>> want synchronization you MUST get some upstream data from the
>> receiver. Just throttling the sender cannot work reliably.
> I'm about to set HWM to 1 and I recalled a thread about this so I've looked it
> up. Totally agree about what's been said so far. The reason I want to do this
> is because I need a way for an event-driven application to determine if data
> has been written to the underlying kernel. This is useful in case the
> application wants to close the socket immediately after writing data. In a
> traditional blocking application, this is easy: just call zmq_close() and
> it'll unblock when done. However, in an event-driven application, the only way
> I can think of imitating this functionality is by setting HWM to 1 and waiting
> until ZMQ_EVENTS indicates writability, then calling zmq_close().

Why you need zmq_close in the asynchronous application in the first
place? Is your application very connection hungry? We never close
zeromq sockets even on fairly low traffic connections, and it works


More information about the zeromq-dev mailing list