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
