[email protected] 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
