[zeromq-dev] Issue 85 & 92

ntupel at googlemail.com ntupel at googlemail.com
Tue Oct 26 17:08:09 CEST 2010


On Sat, Oct 16, 2010 at 12:38 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> Pieter,
>
>>> 1. flag any remaining open sockets as 'closed' without deallocating
>>> them but so that further work on those sockets can properly ETERM
>>> 2. flush any pending messages, with reasonable semantics depending on
>>> the socket type and connection status
>>> 3. return after that work is done
>>> 4. absolutely not block indefinitely when there is no work to do
>
> How would you know no new outbound messages will arrive from a
> particular socket given that it's not closed?
>
> To get that kind of info you need to do a handshake between thread
> executing zmq_term and thread owning the socket.
>
> How it works now is:
>
> 1. Thread A owns socket S
> 2. Thread B calls zmq_term
> 3. B send a signal to A saying "terminate S"
> 4. Next invocation of S-related method from thread A causes the signal
> to be processed and he method returns ETERM.
> 5. Thread A gets ETERM and zmq_closes S. At that point signal is sent
> back to B, finishing the handshake.
>
> Now, the problem is that if there's no S-related call in thread A after
> zmq_term have been called in B, 0MQ cannot finish the handshake (user
> application won't let it get control in thread A).
>
> Here's where zmq_close kicks in: If there have been no previous
> S-related call in thread A, zmq_close processes the signals from B and
> finishes the handshake.
>

Recently I also encountered the problem of zmq_term hanging. My setup
is like this:

1. Thread T1 is spawned and in T1 a context C and a socket S are
created. The socket is bound to a multicast group and does a blocking
recv  for messages.
2. On exit, Thread T2 invokes zmq_term with C (AFAIK zmq contexts can
be shared without synchronization between threads). T2 can not close S
because "Each ØMQ socket belonging to a particular context may only be
used by the thread that created it using zmq_socket()." [1]
3. zmq_term does not return.

My question is - how am I supposed to cleanly shutdown my application,
given that I can't invoke zmq_close on S from T2 and T1 is stuck in a
blocking call?

Many thanks!

-nt

---
[1] http://api.zeromq.org/



More information about the zeromq-dev mailing list