Hi Martin On Tue, Jul 6, 2010 at 1:51 PM, Martin Lucina <m...@kotelna.sk> wrote: > matt_weinst...@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.
Is it time to layout a road-map document and start a zeromq3 development branch on GitHub? This should be where changes that break backwards compatibility will go and can take shape for the next generation of 0mq. I realize the following is known by everybody, but there seems to have been some confusion at times still. " In principle, in subsequent releases, the major number is increased when there are significant jumps in functionality [breakable], the minor number is incremented when only minor features or significant fixes have been added [non-breakable], and the revision number is incremented when minor bugs are fixed." [1] [1] http://en.wikipedia.org/wiki/Software_versioning > >> >> > 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 > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
