On Fri, Jan 17, 2014 at 06:09:15PM +0100, Jason A. Donenfeld wrote:
> On Fri, Jan 17, 2014 at 5:38 PM, Jason A. Donenfeld <[email protected]> wrote:
> > On Fri, Jan 17, 2014 at 5:28 PM, John Keeping <[email protected]> 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.
>
> Oh, and we could avoid a fork() for cached pages...
Good point. I think that probably does make it worthwhile.
It may even make sense for a FastCGI process to do:
while read_request
if not in cache:
process and exit
return_cache
and just rely on the web server restarting us.
_______________________________________________
CGit mailing list
[email protected]
http://lists.zx2c4.com/mailman/listinfo/cgit
