[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