[PATCH 3 of 3 V3] chgcache: implement repocache

Yuya Nishihara yuya at tcha.org
Sat Mar 11 18:50:43 EST 2017


On Sat, 11 Mar 2017 14:54:54 -0800, Jun Wu wrote:
> Excerpts from Yuya Nishihara's message of 2017-03-11 12:54:17 -0800:
> > On Tue, 7 Mar 2017 22:35:59 -0800, Jun Wu wrote:
> > > # HG changeset patch
> > > # User Jun Wu <quark at fb.com>
> > > # Date 1488953311 28800
> > > #      Tue Mar 07 22:08:31 2017 -0800
> > > # Node ID d136f214b3a5bd4698dfd96c641ad73f96a743cb
> > > # Parent  f0bded8d53c5c9a5cfb25d29dd99cf4eb3fb79b2
> > > # Available At https://bitbucket.org/quark-zju/hg-draft 
> > > #              hg pull https://bitbucket.org/quark-zju/hg-draft  -r d136f214b3a5
> > > chgcache: implement repocache
> > 
> > > +repoloadfunctable = {'changelog': loadchangelog}
> > > +
> > > +ui = uimod.ui()
> > > +ui.setconfig('ui', 'allowemptycommit', '1')
> > > +
> > > +repo = localrepo.localrepository(
> > > +    ui,
> > > +    os.path.join(os.environ['TESTTMP'], 'repo1'),
> > > +    create=True)
> > > +repocache = chgcache.repocache(repo, repoloadfunctable)
> > 
> > Suppose a cache object is attached to a repo by chgserver, do we really
> > need a global _cache storage?
> 
> One design goal is to decouple low-level API from repo. i.e. chgcache could
> be used to cache non-repo objects.
> 
> Extensions are an example of non-repo objects that could benefit from the
> design. Workers could send new extensions to the master, and the master
> could have better "extension cache hit rate" after reloading extensions.

I don't get how that would work. Anyway, the extension would register something
in the master process to load into cache. Then, it would be able to access to
the same cache object without using a global _cache dict.

> Unlike the current "start new server for new extensions" behavior. The new
> design allows us to serve the request using the old server sub-optimally,
> and start a more efficient server in the background to replace the current
> one soon.
> 
> A fb-only example is that remotefilelog uses repo-independent packfiles.
> 
> I think the cache state is conceptually attached to the current process,
> instead of repo. Thus a global may actually be a better fit.

Yeah, it will live longer than a repo, and will reside in dispatcher level,
which I don't think mean the data should be globally accessible by anyone.

> We want the
> behavior that "fork()" copies the state, and don't care if fork() should
> copy the repo object or not.

IMHO, fork() is just for parallelism (given we can eventually omit uisetup()
in the master process.)


More information about the Mercurial-devel mailing list