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 <[email protected]> wrote: > > On Thursday, May 10, 2012 01:53:48 PM Pieter Hintjens wrote: > >> On Thu, May 10, 2012 at 3:44 PM, Paul Colomiets <[email protected]> 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
