[zeromq-dev] Fwd: ZMQ Closure - Change of Beginners Documentation

[Mike Pearce]

Hi,

I still believe that reader threads deserve a mention, i.e. threads that are
blocked on a read operation. I imagine that it is not an issue to terminate
any sender or poller threads as they will unblock and I currently do not see
any reason why one should not await this before calling zmq_term. Maybe I am
nieve here and I should instead refer to any thread that is blocked on a zmq
socket operation at the time when zmq_term is called. Reader threads are an
obvious problem for this and a good example because they are blocked and
they have to close their own socket but they will not unblock until zmq_term
is called. So I wanted to be explicit and warn folk of the chicken and egg -
that they must get each thread to close its own socket and that some of
these threads need zmq_term to be called in order to unblock them. Likewise
if they fail to close their socket then zmq_term will block forever. If I
avoid making this message then my mission has failed.

Mike.

On Wed, May 25, 2011 at 3:59 PM, Andrew Hume <andrew at research.att.com>wrote:

> is this really meant to be prescriptive?
>
> it seems like there are design alternatives here;
> for example, i only call zmq_term AFTER i have reaped all my threads.
>
> what i think you are trying to convey is something like:
>
> How a multi-threaded application terminates is beyond teh scope of this
> guide,
> but zmq_term provides support for a control thread to terminate all
> pending zmq operations, such as zmq_recv, with a specific error code
> (ETERM).
> This allows the threads where those operations were running to clean up,
> typically including calling zmq_close on appropriate sockets.
> This in turn will allow zmq_close to terminate.
>
> andrew
>
> On May 25, 2011, at 6:14 AM, Mike Pearce wrote:
>
> Hi Martin,
>
> I was avoiding the detail of ETERM etc but I was referring to the call to
> zmq_close -
>
> - The reader threads are blocked on zmq_recv.
>
> - zmq_term sends an exit command and this releases the blocking (ETERM
> error).
>
> - The reader threads can then call zmq_close in order to get the reaper
> thread to close the socket.
>
> Perhaps its better that this is reworded to
>
> " So by calling zmq_term your reader threads will release and they can then
> call zmq_close before they exit".
>
> Kind Regards,
>
> Mike
>
> On Wed, May 25, 2011 at 12:29 PM, Martin Sustrik <sustrik at 250bpm.com>wrote:
>
>> On 05/25/2011 11:40 AM, Mike Pearce wrote:
>>
>> Minor point:
>>
>>
>>  So by calling zmq_term your reader threads will release
>>>
>> > and they can
>>
>>> then close their sockets and exit.
>>>
>>
>> What you meant was "worker threads will get ETERM error" I presume.
>>
>> Martin
>>
>
> _______________________________________________
> zeromq-dev mailing list
>
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> ------------------
> Andrew Hume  (best -> Telework) +1 623-551-2845
> andrew at research.att.com  (Work) +1 973-236-2014
> AT&T Labs - Research; member of USENIX and LOPSA
>
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110525/6489de1f/attachment-0001.htm>