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. 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. ===========================================================
<<inline: graycol.gif>>
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
