chg and uisetup
quark at fb.com
Fri Jul 8 06:31:37 EDT 2016
The current chg design runs uiseutp/extsetup of other extensions once per
process and that leads to a common pitfall:
If a developer takes a reference to ui in uisetup, or tests some configs
and do wrapfunctions in uisetup, these effects are permanent to the chg
server and the extension may use a stale config forever
(if they do not take the config from reposetup).
This is to discuss how to solve the above issue. I think we have mainly 2
1. Do not run uisetup / extsetup before forking
1. importing (do not run *setup) an extension module is side-effect free
2. ui/extsetups are fast (seems true by my benchmark)
We can just import all potentially needed modules in chgserver.
This looks like a big arch change, and a big step backward because a lot
of code can be removed, and is against the preforking model. But it is
doable within the current framework by providing a blank hgrc, and call
extensions.load() during chgserver startup. The command would be like:
cd /; HGRCPATH=blankhgrc hg serve ... --pre-import some-hgext/*.py
The result will be:
- guaranteed one server per user, minimized server processes
- behave the same with hg, as long as the assumption 1 is true
- confighash is no longer necessary (mtimehash still needed)
- chg client argv passing hasck is no longer necessary
- validate only needs to check mtimehash
- reposetup issue can be easily solved, by chdir
- srcui.walkconfig hack is no longer necessary
- other solutions in this discussion are unnecessary
Personally I like this approach, and want a simpler chg, although it
means reverting a lot of my previous efforts. Not supporting preforking
is fine as I think a more correct approach is another single process
dedicated to answer some defined questions, like partialmatch etc. The
dedicated caching daemon should not be easily killed by ^C.
Convincing an extension to not have side effects outside *setup is also
easier than not taking a ui reference in *setup.
If we want to try preforking model, this can also be implemented as an
option (may need some static config files that the client can read).
2. An official way to let extensions tell chg what needed to be hashed
Consider all kinds of flexibility needed, I think extensions should have
something like hashfunc(ui) and register it to chg (as we don't want
another top-level function):
This is less appealing since extensions have to be aware of chg.
What do you think?
More information about the Mercurial-devel