Excerpts from Yuya Nishihara's message of 2017-01-31 23:36:46 +0900: > > This introduces another race condition that unlinks an innocent socket file. > > I will send a V2 later.
(This actually seems to be a regression after the socketserver refactoring. It probably requires sub-classing "unixforkingservice" in chg to solve properly. It's not too trivial and I'll send fixes after the freeze.) > I have no idea if we can reliably make the socket stop queuing new connections > without destroying the backlog. > > Instead, maybe the client can handle very first ECONNRESET gracefully? After "unlink", the client cannot "connect" by a filesystem address. And chg client does connect by a filesystem address. So it should be reliable (not considering Linux-specific black magic /proc/random-pid/fd/n). I think the "industry standard" about shutting down is to handle all remaining requests while rejecting new ones. The pattern is seen in nginx, squid, thin (a Ruby on Rails server), OpenStack APIs etc. It looks better than retrying in the client. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
