Hi Serge, > While applying Chris's patch based on github.com/sustrik/zeromq2 to > erlzmq I noticed that zmq_term() call blocks the thread running Erlang > VM. I saw on this mailing list someone else sending a patch for this > issue and that the patch was applied: > http://github.com/sustrik/zeromq2/commit/11891ddd5577321a351a1850d28478e97f4b9162 > > but it doesn't seem to solve this particular problem. > > I haven't spent to much time to trace the issue in zmq code base beyond > the fact that I see the execution point is spinning inside > > zmq::ctx_t::~ctx_t () { > ... > while (!zombies.empty()) { > dezombity(); > } > ... > } > > and I also see that while the value of ctx_t::terminated is true, inside > dezombify() sockets in the zombies list have terminated value equal to > false. > > It seems to me that inside zmq::ctx_t::dezombify() the zomby's > terminated flag should respect the value of ctx_t::terminated, and > zmq::socket_base_t::dezombify() should return true in that case (which > is currently ignored when calling process_commands(false, false) inside > that function. > > It looks like a bug to me, though I don't know implications of this > change on other termination scenarios. If the description above is not > clear, I can submit a patch.
It a bug, but the real cause is much more complex. Actually, shutdown is the most complex subsystem of 0MQ so if you want to tackle with it be prepared to spend a lot of time and brain-twisting on it. In any case, finishing "0mq socket migration" work is my top priority atm, so it will be hopefully fixed soon. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
