Right you are. Terminating the context calls socket “stop” which is different 
to the public “close” function.

Cheers,
Matt.

On 11 Sep 2013, at 6:03 pm, [email protected] wrote:

> Hi Matt,
> 
> I'm not sure its legal to close the socket on one thread while reading from 
> another, I just tried it on windows and it aborts rather than returning an 
> error.
> 
> I'm actually trying to avoid doing any manual close myself, my motivation for 
> all this is to use the C++ bindings and let the socket_t destructor do all 
> the work when the application closes, but I need to get all the other threads 
> unblocked and finished before the main class goes out of scope, and this 
> needs to be non-blocking.
> 
> Signalling the sockets to close is precisely how the current zmq_ctx_term and 
> new zmq_ctx_shutdown works, it just uses the internal commands mechanism of 
> zmq rather than requiring a new socket.
> 
> My use case is just for at the end of the application, but I see no reason 
> why the stop mechanism could not be exposed for single sockets if people 
> would find that useful, some sort of zmq_socket_shutdown maybe?  Would this 
> be useful to people?
> 
> Ric.
> 
> <graycol.gif>"Matt Connolly" ---10/09/2013 11:24:41 PM---Couldn’t this be 
> already solved by having the main thread simply close the socket? Sockets are 
> suppo
> 
> From: "Matt Connolly" <[email protected]>
> To:   "ZeroMQ development list" <[email protected]>, 
> Date: 10/09/2013 11:24 PM
> Subject:      Re: [zeromq-dev] non-blocking shutdown command
> Sent by:      [email protected]
> 
> 
> 
> Couldn’t this be already solved by having the main thread simply close the 
> socket?
> 
> Sockets are supposed to be only used on a single thread, but I understood the 
> zmq_term would close the sockets anyway. The result would be that calls to 
> send or receive on the socket would return an error code.
> 
> Alternately, I thought you could use a PAIR socket to send a message from the 
> main thread to the working thread and use that to signal the working thread 
> to close the other socket and end processing. (i.e.: poll on both sockets).
> 
> I guess it depends if you want this thread shutdown to only happen once and 
> finish everything, or if other parts of your app need to keep working.
> 
> -Matt
> 
> 
> On 11 Sep 2013, at 12:31 am, [email protected] wrote:
> 
> Hi All,
> 
> I've just implemented a non-blocking shutdown command name zmq_ctx_shutdown 
> and am concerned about the name.  This is an optional command that can be 
> used when you want to shut down a context that will unblock any blocked 
> operations on other threads but will not then block waiting for all sockets 
> to be closed.
> 
> More details are in the pull request here: 
> https://github.com/zeromq/libzmq/pull/650.
> 
> So do people have any comments on the name?
> 
> Ric.
> 
> 
> 
> 
> ===========================================================
> The information in this email is confidential, and is intended solely for the 
> addressee(s). 
> Access to this email by anyone else is unauthorized and therefore prohibited. 
>  If you are 
> not the intended recipient you are notified that disclosing, copying, 
> distributing or taking 
> any action in reliance on the contents of this information is strictly 
> prohibited and may be unlawful.
> ===========================================================
> 
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> 
> ===========================================================
> The information in this email is confidential, and is intended solely for the 
> addressee(s). 
> Access to this email by anyone else is unauthorized and therefore prohibited. 
>  If you are 
> not the intended recipient you are notified that disclosing, copying, 
> distributing or taking 
> any action in reliance on the contents of this information is strictly 
> prohibited and may be unlawful.
> ===========================================================
> 
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to