On Mon, Mar 19, 2007 at 02:43:54AM +0100, Johannes Schindelin wrote: > > I was talking about the API. The API has to be designed to be > > reentrant. And you get pretty much stuck with the API. And requiring > > reentrance isn't that far off once libgit is there, as I tried to point > > out; it's not really any obscure requirement. > > - it is easy enough to extend the API later, _retaining_ the small and > beautiful functions. Um, look at what we had to do with gethostbyname() and gethostbyname_r(). It wasn't possible to sweep through and fix all of the programs that used gethostbyname(), despite the fact that if a program called gethostbyname(), then called library function which unknowingly to application, could possibly do a DNS or YP lookup (and whose behavior could change depending on some config file like /etc/nsswitch.conf), which would blow away the static information. So if the application tryied to use the information returned by _its_ call to gethostbyname after calling some other library function, it could get some completely random hostname that wasn't what it expected. Yelch! And so we have two API's that libc has to support, gethostbyname(), and gethostbyname_r(), with the ugly _r() suffix, and which in a sane world most programs should use since otherwise they can be incredibly fragile unless the _first_ thing they do after calling gethostbyname is to copy the information to someplace stable, instead of relying on the static buffer to remain sane. (And yet they don't, which means bugs that only show up if optional YP or Hesiod lookups are enabled, etc.) Berkely got it horribly wrong when it tried to start with the "small and beautiful" functions that were non-reentrant, and we've been paying the price ever since. Do we really want to support two versions of the API forever? Is it really that hard to support a reentrant API from the beginning? I'd submit the answer to these two questions are no, and no, respectively. - Ted - 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