From: Andreas Ericsson <ae@op5.se>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Christian Couder <chriscool@tuxfamily.org>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: git to libgit2 code relicensing
Date: Mon, 17 Nov 2008 22:44:39 +0100 [thread overview]
Message-ID: <4921E5C7.5030203@op5.se> (raw)
In-Reply-To: <20081117154040.GO2932@spearce.org>
Shawn O. Pearce wrote:
> 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
next prev parent reply other threads:[~2008-11-17 21:46 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-14 20:59 git to libgit2 code relicensing Andreas Ericsson
2008-11-14 21:33 ` Martin Koegler
2008-11-14 21:46 ` Sverre Rabbelier
2008-11-14 22:57 ` Andreas Ericsson
2008-11-14 22:56 ` Andreas Ericsson
2008-11-15 17:13 ` Martin Koegler
2008-11-14 23:13 ` Linus Torvalds
2008-11-14 23:46 ` Shawn O. Pearce
2008-11-15 4:30 ` David Brown
2008-11-15 5:00 ` Shawn O. Pearce
2008-11-15 8:04 ` Nicolas Pitre
2008-11-15 18:39 ` David Brown
2008-11-15 12:39 ` Miklos Vajna
2008-11-15 13:00 ` Junio C Hamano
2008-11-15 19:33 ` Miklos Vajna
2008-11-15 22:12 ` Pierre Habouzit
2008-11-15 18:49 ` David Brown
2008-11-15 16:39 ` Linus Torvalds
2008-11-15 10:17 ` Andreas Ericsson
2008-11-15 10:28 ` Pau Garcia i Quiles
2008-11-15 11:05 ` Andreas Ericsson
2008-11-15 11:33 ` Pau Garcia i Quiles
2008-11-15 11:52 ` Andreas Ericsson
2008-11-15 18:53 ` David Brown
2008-11-16 1:30 ` Daniel Barkalow
[not found] ` <200811151615.42345.chriscool@tuxfamily.org>
2008-11-16 11:50 ` Andreas Ericsson
2008-11-16 21:00 ` Johannes Schindelin
2008-11-16 21:09 ` Sverre Rabbelier
2008-11-17 7:24 ` Andreas Ericsson
2008-11-17 15:40 ` Shawn O. Pearce
2008-11-17 21:44 ` Andreas Ericsson [this message]
2008-11-20 17:41 ` René Scharfe
2008-11-25 15:19 ` Kristian Høgsberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4921E5C7.5030203@op5.se \
--to=ae@op5.se \
--cc=Johannes.Schindelin@gmx.de \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).