chg and uisetup
yuya at tcha.org
Sat Jul 9 10:07:06 EDT 2016
On Fri, 8 Jul 2016 11:31:37 +0100, Jun Wu wrote:
> 1. Do not run uisetup / extsetup before forking
> Assume that:
> 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.
These assumptions seem legit.
> 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
I don't like the proposed command interface, but I like the big picture of
this idea. It will allow us to get rid of complicated ui hacks at the cost
of designing a dedicated dispatcher for chg.
Maybe we'll need a PoC implementation to make sure that we can take this
> 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)
Still we'll have to hash some environment variables, so the current config-hash
functions won't die.
> - 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.
Something like in-memory key-value store + fork-per-request chg servers?
I'm okay to go without a preforking server. Cache by preforking would be
easier than using a dedicated cache server, but I agree it isn't an ideal
> 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):
> def hashfunc(ui):
> return a-string
> def uisetup(ui):
> chgserver.registerhashfunc(extname, hashfunc)
> This is less appealing since extensions have to be aware of chg.
chg is niche, extension authors won't care for it.
More information about the Mercurial-devel