From: Jeff King <peff@peff.net>
Date: Fri, 03 May 2013 06:02:44 GMT
Subject: Re: [PATCH] lookup_object: prioritize recently found objects
Message-ID: <20130503060244.GA13843@sigill.intra.peff.net>
In-Reply-To: <5183522D.5060405@viscovery.net>

On Fri, May 03, 2013 at 07:59:09AM +0200, Johannes Sixt wrote:

> Am 5/2/2013 17:46, schrieb Jeff King:
> > On Thu, May 02, 2013 at 09:05:01AM +0200, Johannes Sixt wrote:
> >> BTW, do you notice that the function is now modifying an object (the hash
> >> table) even though this is rather unexpected from a "lookup" function?
> > 
> > I think this is fine. The function is conceptually constant from the
> > outside; callers don't even know about the hash table. They just know
> > that there is some mapping. It's similar to the way that lookup_commit
> > will lazily allocate the "struct commit". The callers do not care
> > whether it exists already or not; they care that at the end of the
> > function, they have a pointer to the commit. Everything else is an
> > implementation detail.
> 
> Can we be sure that the function is never invoked in concurrently from
> different threads? I attempted to audit code paths, but quickly gave up
> because I know too little about this machinery.

I didn't check explicitly, but in general such a program would already
need a mutex to synchronize object lookup. Not for lookup_object
specifically, but because lookup_object is mostly used to back
lookup_commit, lookup_tree, etc, which are already not re-entrant
(because they lazily insert into the hash behind the scenes).

-Peff