[zeromq-dev] Issue 85 & 92

[Pieter Hintjens]

On Sat, Oct 2, 2010 at 8:56 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> The question is whether socket should be deallocated or left alone. In
> former case any call currently in the socket or about to enter the socket
> will SEGFAULT. In latter case the main thread terminates dropping the unsent
> messages in the socket.

I don't think SEGFAULT counts as a valid semantic.  What should happen
IMO is that sockets are left alone but all attempts to do further work
on them will cause an error.

You can reasonably add the semantic in 2.1 that in order to flush a
socket properly you must explicitly call zmq_close.  However even that
is not consistent with normal POSIX process semantics.  Open file
handles are correctly flushed and closed on a normal exit even if you
don't explicitly close them.

>> zmq_term should not block forever when there is no work to do, whether
>> or not I closed any sockets beforehand.  If the API detects an error
>> it should report it.  It should not cause my application to hang.
>
> SO_LINGER should be implemented to limit the amount of time to spend trying
> to send messages. To be done later. However, it's orthogonal to the problem
> above.

>> The question is, what BSD socket semantics are you emulating here?
>> There is no requirement in POSIX that sockets be closed before exiting
>> an application, it happens automatically at exit.
>
> I am emulating behaviour of OS kernel as such. Kernel stays in place even if
> you close the socket. That gives it a chance to send unsent messages.

You're emulating the behaviour of a buggy system right now.  A
terminate call that blocks forever despite there being no work in the
system is simply broken.  Saying this is how the kernel works is not
an answer.  I'm asking you to point to any other libraries or calls
that work like this.

Your call, Martin.  I'm pretty sure the new behavior of zmq_term will
trip up a lot of people.

-
Pieter Hintjens
iMatix - www.imatix.com