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

Peter Alexander vel.accel at gmail.com
Wed Jul 7 05:53:07 CEST 2010


Hi Martin

On Tue, Jul 6, 2010 at 1:51 PM, Martin Lucina <mato at kotelna.sk> wrote:
> 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.

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 at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list