On 7/7/2010, "Dhammika Pathirana" <[email protected]> wrote:
>But how is this different from network or remote host queuing/dropping >messages? >Sending queued messages doesn't really guarantee delivery of messages. Of course this change doesn't *guarantee* anything has been delivered. But that's not the point. Imagine you're using a standard TCP socket, and you do: accept (...); write (...); close (...); Surely you expect that the data you sent down that socket with the write() should pop out the other end *if that other end is still there*? With the current zmq_close() semantics that won't happen. Bringing this in line with the standard close() semantics is what my change proposes. If you need a better example, imagine what you're writing to is a file and not a socket :-) -mato _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
