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

[Pierre-Yves David]

On 07/18/2015 06:52 AM, Yuya Nishihara wrote:
> On Sat, 18 Jul 2015 02:04:06 +0200, Pierre-Yves David wrote:
>> On 07/14/2015 04:15 PM, Yuya Nishihara wrote:
>>> On Tue, 14 Jul 2015 12:50:59 +0200, Pierre-Yves David wrote:
>>>> On 07/12/2015 03:37 PM, Yuya Nishihara wrote:
>>>>> On Sun, 12 Jul 2015 14:27:41 +0100, Pierre-Yves David wrote:

At that point, We've been talking about this for far too long, someone 
(ie: yuya as chg owner) should agree with Laurent on a viable plan so we 
can just go for it.

>>>>>> This server lifecycle being controled by its many client seems strange
>>>>>> to me. In my opinion, the only responsibility the client should have
>>>>>> regarding the server is to get one rolling if it does not already
>>>>>> exists. All life cycles decisions (shutdown//reload if config changed,
>>>>>> shutdown after timeout) should be done by the server, probably controled
>>>>>> by config option.
>>>>>
>>>>> I won't argue if the server can restart itself. I just don't like the
>>>>> following:
>>>>>
>>>>>     1. server shutdown by itself if config changed
>>>>>     2. but client have to start new server
>>>>
>>>> I'm not sure what is your issue with it. I see this as expressable as:
>>>>
>>>>     Client start server if none is available.
>>>
>>> The patches for chg do "client starts new server if it said dirty and
>>> would be shut down by itself."
>>>
>>> https://bitbucket.org/lc2817/chg/commits/483b35203d92d450f7e969b0491e0e991bef6094
>>>
>>>    1. client start server if none is available
>>>    2. talk to server
>>>    3. server says it is dirty (and shut down by itself)
>>>    4. client start new server assuming that dirty server would go away
>>>
>>> So the client have to know if the server is dirty or not anyway. We can
>>> eliminate (2) and (3) if the client can check if config files are dirty.
>>
>> Not that the server says "I'm shutting down" which is broader than
>> "dirty" (so the assumption it is going away it is going away is
>> sensible). As we have to handle the case where the server is shutting
>> down anyway (cf below). Having all the config checking in the server
>> seems simpler as a start.
>
> Even if the server has the responsibility of checking dirty configs, it does
> not need hacks [1] to shut down by itself. Because the client have to know
> the server is dirty anyway, it can do kill-then-restart the server.

I think having the server responsible for shutting down make sense. I 
also think we'll want server shutting down capability for other things 
(as shutdown after a timeout)

>   [1]: these monkey patching are necessary to set the dirty flag before fork()
>        https://bitbucket.org/lc2817/chg/commits/fcb582d7bde9
>        https://bitbucket.org/lc2817/chg/commits/97e28d236303
>
> Also, it won't work if we want to restart the server when HGPLAIN is changed,
> for example.
>
>   1. client: connect
>   2. master-server: check dirty
>   3. master-server: fork() child-server
>   4. master-server: shut down if dirty
>   5. child-server: tell client that master-server is shutting down if dirty
>   ...
>   6. client: send environment variables to child-server

environment variable will be an headache on their own. Do you think we 
should have a plan for them before moving forward?



-- 
Pierre-Yves David