[zeromq-dev] zmq_close() semantics and handling outstanding messages
Martin Lucina
mato at kotelna.sk
Wed Jul 7 09:10:17 CEST 2010
On 7/7/2010, "Dhammika Pathirana" <dhammika at gmail.com> 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
More information about the zeromq-dev
mailing list