chg and uisetup

[Yuya Nishihara]

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

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

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