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