Hi all,
while implementing a 0MQ architecture which needs to dynamically create and
destroy sockets during operation I ran into the current behaviour of
zmq_close() being semantically different from the standard close() system
call.
Consider a scenario where we wish to send a bunch of messages, then close
the socket:
zmq_send (s, ...)
zmq_send (s, ...)
zmq_send (s, ...)
zmq_close (s)
The current behaviour is that zmq_close() will discard any messages which
have been queued ("sent") with zmq_send() but have not yet been pushed out
to the network. Contrast this with the behaviour of the close() system call
on a standard socket where the call means "please make this socket go away,
but finish sending any outstanding data on it asynchronously if you
can"[1].
In my opinion the proper solution is to use the same semantics as the
close() system call, in other words, zmq_close() shall invalidate the
socket from the caller's point of view so no further operations may be
performed on it, but 0MQ shall send any outstanding messages in the
background *as long as a endpoint for those messages still exists* before
destroying the socket "for real".
This would mean a second change to the API which would make zmq_term() a
blocking call, since it would need to wait until all outstanding messages
are sent. The analogous functionality for the close() system call is
handled by the OS kernel -- obviously if the OS shuts down then data will
be lost.
The downside is that zmq_term() could freeze for an arbitrary amount of
time if the remote end is "stuck". For applications where this is
undesirable it would mean adding a "KILL" flag or separate zmq_term_kill()
function which means "we don't care, really go away now".
Please let me know your opinions on this change; ultimately I think it's
the right way to go especially if OS integration of 0MQ sockets is (a long
way) down the road.
-mato
[1] This behaviour can be changed using the SO_LINGER option, we'd probably
want to implement a similar option for 0MQ sockets.
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
