From mboxrd@z Thu Jan  1 00:00:00 1970
From: john at keeping.me.uk (John Keeping)
Date: Fri, 17 Jan 2014 16:53:33 +0000
Subject: The road to v0.10.1 or v0.11
In-Reply-To: <CAHmME9rUbNW7Jkh2TDiXTJP+Z=+d7SgdgvWp3nPkcwL9ZdPdiQ@mail.gmail.com>
References: <CAHmME9p6ubctzVTwRurFW+Vg9fYLwjKAoPr6_MwbKHJiHKv_YA@mail.gmail.com>
 <20140117162851.GM7608@serenity.lan>
 <CAHmME9rUbNW7Jkh2TDiXTJP+Z=+d7SgdgvWp3nPkcwL9ZdPdiQ@mail.gmail.com>
Message-ID: <20140117165333.GN7608@serenity.lan>

On Fri, Jan 17, 2014 at 05:38:29PM +0100, Jason A. Donenfeld wrote:
> On Fri, Jan 17, 2014 at 5:28 PM, John Keeping <john at keeping.me.uk> wrote:
> > I really can't see this being sensible without moving to libgit2.  As
> > long as we stick with libgit.a then we need to fork for each request so
> > I'm not sure there's much benefit to supporting FastCGI without moving
> > to something that lets us free resources when we're done processing a
> > request.
> 
> The advantage would be not having to reparse the config and scan for
> repos on every.single.solitary.request.

But scan for repos is caught by the cache most of the time, and
presumably even if we run persistently we still need to do that
periodically (or use inotify); or do we just rely on the process being
replaced when the set of repositories changes?