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

[Mike Pearce]

Hi,

For information, I am not convinced that ETERM will always be the exit value
returned. In reality It does not matter and I prefer not to test for this
value. My loop is of the form

while (!stopped)
{
    rc=zmq_recv();
    if (rc!=0)
    {
       if (stopped)
          break;
    }
}
zmq_close();

In the main loop -

reader.stop();  // sets stopped=true
zmq_term();
reader.wait(100) // wait for the reader thread to finish etc.

So it is not so important what zmq_recv returns because I know that I am
exiting.

When I looked at messageBox.recv for nbytes=0 I found that it is called from
several call points and not all of them cater for ETERM. I am not convinced
that ETERM is properly implemented but I did not spend the time to analyse
each call point to see if it could occur during a shutdown scenario.

Cheers,

Mike.

On Wed, May 25, 2011 at 4:19 PM, Mike Pearce <mike at kaew.be> wrote:

> 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/60deb369/attachment-0001.htm>