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).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html