Re: git to libgit2 code relicensing

From: Andreas Ericsson <ae@op5.se>
Date: Nov 17, 2008, 21:44 UTC
Message-ID: <4921E5C7.5030203@op5.se>
In-Reply-To: <20081117154040.GO2932@spearce.org>

Shawn O. Pearce wrote:

Show 18 quoted lines

> Andreas Ericsson <ae@op5.se> wrote:
>> "Copy-rewrite", naturally. Being able to lift much of the data-munging code
>> is a great benefit. It's basically just the revision traversal (which is
>> heavy on state-dependant code) that I haven't quite figured out how to do
>> yet, but I believe Shawn's idea of using revision pools is most likely the
>> way to go. Each application has to make sure a pool isn't modified by more
>> than one thread, but each application can have as many pools as it likes.
> 
> I also like Pierre's idea of using annotation data in different
> annotation pools, and storing the rewritten parents in such a pool.
> Then an application can more easily reuse a revision pool, by just
> tossing the rewritten parent pool, or any other annotations it
> wants to recompute.
> 
> It may still be important to have revision pools and make them
> not thread-safe, so we can void fine-grained locking costs in
> the library during the tight revision traversal loops.
>

Well, since git_revpool (I've renamed it in my tree, as I had a hard time not pronouncing it "rev pointer" in my head) is a variable the user gets back from us, it's about as thread-safe as the various IO interfaces. That is, if several threads try to write at once, weird things happen. That's just something the application writer has to take care of though, and we should make sure to mark the revpool as "const" in functions that will only read from it without modifying it.

Speaking of threads though; I think I've solved the thread-local storage problem for libgit. At least for pretty much all compilers we care about (gcc, Intel C, MSVC, MSVC++) and a slew of others, which means we can probably use a saner error-handling now. Personally I think that's something we can benefit greatly from, as many functions return "int" where they should return a pointer, only to accommodate error handling.

I'll get those commits reordered and publish what I've got right now. http://git.op5.org/git/?p=git/libgit2.git;a=summary will have most of the stuff in an hour or so.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231