Oh, I forgot the mention another point about this. I have started to put time.sleep(?) calls at the end of my zmq applications because of this. But, this has a huge problem that is almost impossible to fix with the current API. The amount of time I need to sleep before calling zmq_term is unpredictable and depends on things like:
* This number of outstanding messages. * The size of the outstanding messages. There isn't really any way of knowing these things in general, so if my application will have lots of large messages, I have to put in *really* long sleeps before shutting down. I would much rather have zmq_term block for exactly the right amount of time. Cheers, Brian On Tue, Jul 6, 2010 at 10:24 AM, Martin Lucina <[email protected]> wrote: > Hi all, > > while implementing a 0MQ architecture which needs to dynamically create and > destroy sockets during operation I ran into the current behaviour of > zmq_close() being semantically different from the standard close() system > call. > > Consider a scenario where we wish to send a bunch of messages, then close > the socket: > > zmq_send (s, ...) > zmq_send (s, ...) > zmq_send (s, ...) > zmq_close (s) > > The current behaviour is that zmq_close() will discard any messages which > have been queued ("sent") with zmq_send() but have not yet been pushed out > to the network. Contrast this with the behaviour of the close() system call > on a standard socket where the call means "please make this socket go away, > but finish sending any outstanding data on it asynchronously if you > can"[1]. > > In my opinion the proper solution is to use the same semantics as the > close() system call, in other words, zmq_close() shall invalidate the > socket from the caller's point of view so no further operations may be > performed on it, but 0MQ shall send any outstanding messages in the > background *as long as a endpoint for those messages still exists* before > destroying the socket "for real". > > This would mean a second change to the API which would make zmq_term() a > blocking call, since it would need to wait until all outstanding messages > are sent. The analogous functionality for the close() system call is > handled by the OS kernel -- obviously if the OS shuts down then data will > be lost. > > The downside is that zmq_term() could freeze for an arbitrary amount of > time if the remote end is "stuck". For applications where this is > undesirable it would mean adding a "KILL" flag or separate zmq_term_kill() > function which means "we don't care, really go away now". > > Please let me know your opinions on this change; ultimately I think it's > the right way to go especially if OS integration of 0MQ sockets is (a long > way) down the road. > > -mato > > [1] This behaviour can be changed using the SO_LINGER option, we'd probably > want to implement a similar option for 0MQ sockets. > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo [email protected] [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
