On Wed, Jul 7, 2010 at 6:39 PM, Martin Lucina <m...@kotelna.sk> wrote:
> Read up on the manuals for close() and setsockopt(). > > Following the principle of least surprise and consistency with standard > sockets, zmq_close() should not be a blocking call by default since > close() isn't either. The standard Linux man pages on close() and setsockopt() are not very helpful. Do you have a URL to whatever manual page you're referring to? However... following the principle of least surprise, send() would block and apps would not lose data just because they forgot to sleep(<insert random number here>). We're already breaking the principle of least surprise in a major way, obviously. IMO it would be considerably less surprising to have zmq_close() flush data, than to have data loss. Further, close() _is_ a blocking call according to the man pages I'm looking at (which is why it may return EINTR) though it's unclear whether close() flushes data or not. > As I mentioned in my original email you can alter the default behaviour > of close() on sockets to be blocking, or even to do roughly what > zmq_close() does now by manipulating the SO_LINGER socket option. You're comparing TCP sockets with 0MQ sockets but it's not the right comparison because send() is working so differently. What we're doing is caching data in application memory and deciding on semantics for flushing that cache. As you said yourself, the accurate comparison is between 0MQ sockets and a file system. So, does fclose() flush data? Yes, it does. Does it do a fsync to ensure the data is actually written to disk? No, that's the OS's problem. It's precisely the same here. Still, it's moot IMO, the only difference between flushing in zmq_close() and zmq_term() will be for applications that create and destroy many sockets, which is probably a buggy pattern. -Pieter _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
