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

Yuya Nishihara yuya at tcha.org
Thu Jul 9 09:23:52 CDT 2015


On Wed, 8 Jul 2015 16:55:09 +0000, Laurent Charignon wrote:
> On Jul 8, 2015, at 6:32 AM, Yuya Nishihara <yuya at tcha.org<mailto:yuya at tcha.org>> wrote:
> On Tue, 7 Jul 2015 15:21:08 +0000, Laurent Charignon wrote:
> On Jul 7, 2015, at 5:54 AM, Yuya Nishihara <yuya at tcha.org<mailto:yuya at tcha.org>> wrote:
> On Mon, 6 Jul 2015 11:42:40 -0700, Laurent Charignon wrote:
> # HG changeset patch
> # User Laurent Charignon <lcharignon at fb.com<mailto:lcharignon at fb.com>>
> # Date 1435794507 25200
> #      Wed Jul 01 16:48:27 2015 -0700
> # Node ID 38cd2c6265855f0a8e65e02e2cc181921df498ca
> # Parent  2748bf78a5bf610da4f2d90fd1eea19a3b360c04
> util: add method to hash nested combination of python data structures
> 
> The goal of this series of patches is to have a method to compute the hash of
> config objects. This will enable restarting the command server when the config
> change.
> 
> I'm curious who and how the command server will be restarted. This patch seems
> to imply that we can't rely on the mtime of the config files.
> 
> - I will send you a pull request for that
> 
> A pull request? Oh, it seems you're playing with chg, thanks.
> 
> Yep, I actually sent it, you can have a look :)

Thanks, I'll look into it.

> - We can, but if the config ends up being the same we don't want to restart
> the command server preemptively.
> 
> Hmm, because config files are edited by user, I think we can assume that the
> mtime change denotes the content change in most cases.
> 
> How about automated deployment through configuration tools?

Does the deployment tool run with chg?

> What if the client adds a space or a comment, do we really want to
> restart the server then?

Well, it's acceptable cost for me. It's just an extra ~100msec, is shorter than
I type C-x C-s C-x C-c.

> My idea for chg is:
> 
> 1. server writes mtime (or sha1 hash) and path to "rcmtimes" file at startup
> 2. client read "rcmtimes" to detect config change (everything done in C *1)
> 3. kill -TERM, wait and respawn server, or kill -HUP ?

(OT: we'll also want to detect change on mercurial/__version__.py)

> Your idea seems simpler to implement, however, how do you deal with clients
> that were connected to the same server before, what is going to happen to them?

Perhaps the forked server process will stay until the client disconnects. If
we want to make the main process take care of forked processes, maybe we should
implement the signal handler appropriately. I didn't carefully write chg to be
safe for a startup/shutdown race.

My position for this patch:

 - it won't be a general solution for the issue of the command server
   https://mercurial.selenic.com/wiki/CommandServer#Known_issues
 - because in common scenario of using pipe, server and client are 1:1,
   a single long-lived connection + many "runcommand" requests,
   which is very different from how chg works
 - so for now, I don't think this patch will be useful in Mercurial core

Regards,


More information about the Mercurial-devel mailing list