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

[Martin Lucina]

matt_weinstein at yahoo.com said:
> > 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".
> >
> Would this be logical to implement as a new zmq_setsockopt() option?

Ultimately the semantics will *have* to change if 0MQ sockets would be
integrated into the OS.

If your primary priority is backward compatibility, then yes, the "new"
behaviour would have to become a socket option. I'm not convinced that
keeping incorrect behaviour for the sake of backward compatibility is a
good idea and my view is that the current behaviour is definitely incorrect
in the long run.

> 
> > 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.
> 
> And I'm looking for a way to dynamically change the number of  
> concurrent user threads available for a context, so maybe it's time  
> for zmq_setcontextopt()? ;-)

Probably. get/setcontextopt() are the equivalent of sysctl() or similar in
the OS space.

-mato