[zeromq-dev] zmq_close() semantics and handling outstanding messages

[Martin Sustrik]

Hi,

I would say the zmq_close behaviour should mimic Berkeley socket close 
behaviour, including SO_LINGER option and all the shutdown modes it 
provides.

(One thing that strikes me is that there's no timout for trying to send 
the data in the default case, which just begs to be exploited in a DoS 
attack. But that's beside the point.)

The only real problem is zmq_term behaviour. 0MQ context is meant to 
play the same role as OS plays for BSD sockets. Following the analogy, 
closing context should drop all the pending data same way as OS drops 
all the data pending in TCP tx buffers on shutdown.

The problem with this approach is that the behaviour is 
non-deterministic (you don't know whether data were sent when shutting 
down). Non-deterministic behaviour is OK for OS shutdown, but doesn't 
work well for application shutdown (i.e. zmq_term).

A straightforward behaviour for zmq_term would be to block until all the 
sockets are deallocated -- each depending on it's SO_LINGER policy.

(This could obviously result in deadlock on zmq_term, but that's beside 
the point once again I think.)

Thoughts?
Martin