[PATCH 1 of 3 V2] util: add method to hash nested combination of python data structures
pierre-yves.david at ens-lyon.org
Sat Jul 18 13:31:42 CDT 2015
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
>>>>> 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."
>>> 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  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)
> : these monkey patching are necessary to set the dirty flag before fork()
> 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?
More information about the Mercurial-devel