Well, hopefully I haven't broken anything, it looks OK to me. For the record, a way I found to make this trigger every time is to put a 1 second sleep between the unlock and the relock, and a 0.5 second sleep at the start of reaper_t::process_reaped (without the delay in process_repeaped the second stop gets sent but the mailbox gets closed before its processed).
Ric. From: "Pieter Hintjens" <[email protected]> To: "ZeroMQ development list" <[email protected]>, Date: 06/11/2013 03:45 PM Subject: Re: [zeromq-dev] Bad file descriptor in rm_fd() Sent by: [email protected] On Wed, Nov 6, 2013 at 4:31 PM, <[email protected]> wrote: > > OK, so investigating this, I think https://github.com/zeromq/libzmq/pull/738 > may solve the issue. > > What I think is happening is ctx_t::terminate, we set the state to > terminating then immediately unlock and relock the slot_sync lock. > > If the last destroy_socket gets in while we are brief unlocked, both > destroy_socket and terminate will issue a reaper->stop (), so we will call process_stop twice. > > Anyone know why we do the unlock/relock dance? I'd guess this was an attempt by Sustrik to make the shutdown work properly. It's always been a difficult part of the design. -Pieter _______________________________________________ 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
