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

[Yuya Nishihara]

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> wrote:
> > On Mon, 6 Jul 2015 11:42:40 -0700, Laurent Charignon wrote:
> >> # HG changeset patch
> >> # User Laurent Charignon <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.

> - 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.

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 ?
 4. connect to command server

 *1) C implementation of sha1 can be borrowed from Python or other free software

This way, client doesn't need to talk to server to see if config is dirty.

Regards,