[PATCH 1 of 3 V2] util: add method to hash nested combination of python data structures

Yuya Nishihara yuya at tcha.org
Tue Jul 21 09:41:00 CDT 2015

On Mon, 20 Jul 2015 16:38:18 +0000, Laurent Charignon wrote:
> > On Jul 20, 2015, at 5:00 AM, Yuya Nishihara <yuya at tcha.org> wrote:
> >  1. client: connect
> >  2. server: fork child-server
> >  3. client: send environment variables
> >  4. client: ask if dirty
> >  5. child-server: tell dirty if config, HG*, LC_*, etc. are changed
> >  6. client: disconnect, kill and restart server, reconnect, ...
> I am still concerned with the case of other clients connected to the server
> before step 6. The client cannot ignore that and kill the server, isn't it?

That is the same kind of problem as the startup race I mentioned before.
If two clients try to start new server at (1) or (6), one would fail with
EADDRINUSE (or two would success and one of them become unreachable thanks to

If I understand it, this problem can't be solved by shutting down the server
without kill. For example,

 1. client-A: connect
 2. client-B: connect
 3. server: fork child-server-A, then shut down because dirty
 4. child-server-A: tell dirty to client-A
 5. client-A: start new server
 6. client-B: fail with ECONNRESET or EPIPE ?
 7. client-C: connect, get ENOENT or ECONNREFUSED (because server isn't ready)
 8. client-C: start new server

So, IMO, we'll need a lock to protect kill/start process. I have experimental
patches that uses a unique --daemon-pipefds file.


It will be extended to avoid double kills.

 1. child-server-A: tell dirty to client-A
 2. client-A: take lock, kill, restart and wait
 3. child-server-B: tell dirty to client-B
 4. client-B: can't take lock, just wait
 5. server: ready, delete lock

If (4) and (5) are swapped, the client-B could kill the new server. But I
think it can be ignored because the server won't start so fast.

More information about the Mercurial-devel mailing list