[zeromq-dev] HWM behaviour & blocking

Justin Karneges justin at affinix.com
Thu Jun 28 20:06:38 CEST 2012


On Thursday, June 28, 2012 03:50:57 AM Paul Colomiets wrote:
> 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
> nice.

It's really just for functional completeness of my event-driven wrapper. The 
only time I can see this coming up in practice is an application that pushes a 
message just before exiting.

For now, I set ZMQ_LINGER to 0 when a socket object is destroyed, making the 
above application impossible to create. What I'm thinking of doing now is 
offering an alternate, blocking-based shutdown method. This would violate the 
spirit of my wrapper, but may work well enough for apps that finish with a 
single socket doing a write-and-exit.

Justin



More information about the zeromq-dev mailing list