Pieter Hintjens <p...@imatix.com> writes: > That bug hasn't been fixed IMO. > > So what you're saying is that simply doing a "sleep (n)" inside > zmq_ctx_term would actually work better than LINGER n seconds (where n > is less than infinity)... LOL.
Hi, not really I meant: ---------------------------------------------------------------------- set_linger(n); zmq_ctx_term(); ---------------------------------------------------------------------- is the same as: ---------------------------------------------------------------------- internally_stop_sending_msg_and_drop_queued_msg(); set_linger(0); sleep(n); zmq_ctx_term() ---------------------------------------------------------------------- At least that is my suspicion. Probably for DEALER/ROUTER, but I do not know if at both ends or not. So there is much behaviour to explore and document... Based on above I meant further setting LINGER to any other value as '0' or 'inf' is pointless. So while 2 seconds or 30seconds from https://github.com/zeromq/libzmq/pull/1253 might make sense from documentation point of view, in practise it does not help as the implementation seems to be broken. And even if libzmq would work as documented the apprach sounds racy. Basically I think there will be no guarantee that a message of any size will be delivered in any amount of time. We used ZMQ for short-living sessions(exchange data between processes over TCP on localhost for a few seconds, then one or both processes would stop), so in order to achieve delivery of all messages if one endpoint wants to disconnect, I implemented a special 'exit'-handshake, so that both processes could deal with the situation. So I think too that "Any reliable protocol has to do handshaking, as we already know." from https://github.com/zeromq/libzmq/pull/1253#issuecomment-62477269 is the way to go. kind regards Frank _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
