[zeromq-dev] behavior of zmq_term in 2.1.0

[Chuck Remes]

On Nov 27, 2010, at 3:31 PM, Martin Sustrik wrote:

> On 11/27/2010 10:24 PM, Chuck Remes wrote:
>> This blocking behavior was raised as an issue in #85.
>> 
>> https://github.com/zeromq/zeromq2/issues#issue/85
>> 
>> That ticket hasn't been updated, but the discussion did include references to SO_LINGER which I see has been implemented (and documented) as the ZMQ_LINGER socket option. Since the unwanted behavior (packets dropped when zmq_term() is called) has been solved by the addition of ZMQ_LINGER, can we now consider the blocking behavior of zmq_term() to be a bug?
>> 
> No. It's the only way to achieve the "don't drop the packets on exit" 
> behaviour I can imagine. Except for moving 0MQ into kernel space, of course.

Wait a second...

Let's assume that zmq_term() calls zmq_close() on each known socket.

Why can't zmq_term() block for a *maximum* of milliseconds as set on each socket by the ZMQ_LINGER option? If the goal is to avoid dropping packets when exiting, then zmq_term() can interrupt those sockets (so that no additional messages can be queued) and then wait ZMQ_LINGER milliseconds before socket termination is complete.

At that point, the context should be able to exit cleanly.

Doesn't that solve the original problem of dropping packets on exit? What am I missing?

cr