From mboxrd@z Thu Jan 1 00:00:00 1970 From: john at keeping.me.uk (John Keeping) Date: Thu, 16 Jan 2014 13:08:44 +0000 Subject: Policy on global variables In-Reply-To: References: <20140116005912.GA20306@dcvr.yhbt.net> <20140116104751.GA26678@dcvr.yhbt.net> Message-ID: <20140116130844.GF7608@serenity.lan> On Thu, Jan 16, 2014 at 12:31:15PM +0100, Jason A. Donenfeld wrote: > On Thu, Jan 16, 2014 at 11:47 AM, Eric Wong wrote: > > Lars Hjemli wrote: > >> Supporting something like FCGI in cgit will require a fork(2) for each > >> request, before invoking libgit.a functions, since these functions are > >> not generally reentrant (they tend to use global state and/or > >> inconveniently die(3)). > > > > Unfortunately true for now, but libgit.a could evolve (or cgit can use > > something like libgit2 instead). > > Cgit is unlikely to move to libgit2 in the near future. (Unless > someone is willing to do the job and argue for why it's preferred over > mainline git, beyond its reentrancy...) > > I guess, though, libgit.a is likely to never evolve to receive > reentrant functions and do away with die() (though the die calls could > easily be circumvented by hooking libc's exit...yuck), because libgit2 > exists for this reason. I had a look at porting to libgit2 about a year ago and it mostly isn't too bad. IIRC the only problematic area is the graph output which we currently get from libgit.a but would have to do ourselves if we switch to libgit2.