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

[Martin Sustrik]

On 05/26/2011 07:03 PM, Pieter Hintjens wrote:
> On Thu, May 26, 2011 at 3:06 AM, Mike Pearce<mike at kaew.be>  wrote:

>> 2. It states that if the users application is doing a blocking read then
>> zmq_term is the means by which this blocked read will get unblocked. By
>> implication an application that implements a blocked read will need to be
>> multithreaded.
>
> This isn't accurate, though. A classic way of exiting a blocked read
> is to receive a message, or to be interrupted by a signal like SIGINT.

This was the case with old versions of 0MQ.

People were advised to send a termination message to worker threads to 
shut them down.

This added a lot of boilerplate code to any multithreaded application -- 
establishing a pub/sub topology for distributing the termination message 
from the main thread to worker threads, using zmq_poll in each worker 
thread instead of simple zmq_send/zmq_recv so that it can monitor both 
the "working" socket and "termination" socket etc.

The whole ZMQ_TERM semantics was implemeted as an attempt to get rid of 
this boilerplate code. What it does it basically handles the termination 
handshake between main thread and worker threads behind the scenes:

1. zmq_term() sends termination request from main thread to worker threds
2. each worker thread is notified about the termination by getting 
ZMQ_TERM from either next or ongoing call to any zmq* function
3. at this point the worker thread is free to do any clean-up
4. finally, worker thread closes all its sockets which generates a 
termination acknowledgement which is passed back to the main thread
5. receiving acknowledgements from all worker threads cause zmq_term to 
unblock
6. the main thread can safely terminate the process now

Martin