[zeromq-dev] Fwd: ZMQ Closure - Change of Beginners Documentation
andrew at research.att.com
Wed May 25 15:59:01 CEST 2011
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.
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,
> 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.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev