Re: Policy on global variables
Lars Hjemli hje...@gmail.com wrote: On Thu, Jan 16, 2014 at 2:00 AM, Jason A. Donenfeld ja...@zx2c4.com wrote: On Thu, Jan 16, 2014 at 1:59 AM, Eric Wong normalper...@yhbt.net wrote: This. I prefer we keep passing around the ctx variable to keep the code more flexible for future reuse. Of course, IIRC git itself has this limitation, too... Can anyone confirm or deny this? Is it a pointless endeavor because of git's design? 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 mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: Policy on global variables
On Thu, Jan 16, 2014 at 11:47 AM, Eric Wong normalper...@yhbt.net wrote: Lars Hjemli hje...@gmail.com 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 am therefore tempted to follow Lars' suggestion, and merge lf/global-ctx. ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: Policy on global variables
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 normalper...@yhbt.net wrote: Lars Hjemli hje...@gmail.com 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. ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: Policy on global variables
On Thu, Jan 16, 2014 at 2:08 PM, John Keeping j...@keeping.me.uk wrote: 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. Are there any downsides of doing this? I know we've put a lot of work into cozying up with internal git utility functions and their build system. Would we have to reimplement a lot of this? Would it be worth it? Are there general benefits of using libgit2 over what we have now? Are there general downsides? More importantly, is this something you would be willing to do, if we decided it was the best direction? ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: Policy on global variables
On Thu, Jan 16, 2014 at 07:38:02PM +0100, Jason A. Donenfeld wrote: On Thu, Jan 16, 2014 at 2:08 PM, John Keeping j...@keeping.me.uk wrote: 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. Are there any downsides of doing this? I know we've put a lot of work into cozying up with internal git utility functions and their build system. Would we have to reimplement a lot of this? Would it be worth it? Are there general benefits of using libgit2 over what we have now? Are there general downsides? Given the CGit and Git are both GPLv2, we could always just take strbuf.[ch] and the argv-array bits from git.git and copy them into CGit. Likewise the test suite could switch to using Sharness with very little effort. So I don't think the recent changes towards using more bits of Git actually have too much impact here. More importantly, is this something you would be willing to do, if we decided it was the best direction? I won't have time to do this in the near future. The first step in this direction may actually be useful even if we stick with embedding libgit.a. Re-writing the commit graph drawing ourselves could allow prettier output than the ASCII we inherit from Git. ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: Policy on global variables
On Thu, Jan 16, 2014 at 10:26:08PM +0100, Jason A. Donenfeld wrote: On Thu, Jan 16, 2014 at 10:21 PM, John Keeping j...@keeping.me.uk wrote: The first step in this direction may actually be useful even if we stick with embedding libgit.a. So what do you think ought to be done with the global-ctx patch? Merge it, and then refactor afterward (whenever we step in this direction), to get rid of the global? Or use what we have now (without the patch) as a starting point for gradually getting rid of the global? I'm not sure it makes much difference either way. Even if we use libgit2, providing we're not processing more than one request at once we can still use a global cgit_context. ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: Policy on global variables
On Thu, Jan 16, 2014 at 10:36:34PM +0100, Jason A. Donenfeld wrote: On Thu, Jan 16, 2014 at 10:34 PM, John Keeping j...@keeping.me.uk wrote: I'm not sure it makes much difference either way. Even if we use libgit2, providing we're not processing more than one request at once we can still use a global cgit_context. Well, the idea of moving to libgit2, in the first place, would be to benefit from its reentrancy, so that we could process multiple requests at once (potentially). At once (as in in parallel), or without needing to fork for every request? I think that many requests serially in the same process is a much more likely scenario (that's what FastCGI does); in that case all we need to do is clean up after each request and it doesn't make much difference if that state is global or passed down through the functions that need it. ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: Policy on global variables
On Thu, Jan 16, 2014 at 11:20 PM, John Keeping j...@keeping.me.uk wrote: At once (as in in parallel), or without needing to fork for every request? I think that many requests serially in the same process is a much more likely scenario (that's what FastCGI does); in that case all we need to do is clean up after each request and it doesn't make much difference if that state is global or passed down through the functions that need it. Yea, that's a good point I suppose. Parallel request capability would still be nice, in some abstract sense, but I guess it's not clear what the benefits would be practically. I'll merge Lukas' patch, and we'll refactor later if necessary. ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: Policy on global variables
Jason A. Donenfeld ja...@zx2c4.com wrote: In theory, passing around the variable, and not relying on a global, is better. It allows us at somepoint to have multiple contexts, for, say, implementing FastCGI or an event loop single-process multi response model. This. I prefer we keep passing around the ctx variable to keep the code more flexible for future reuse. Of course, IIRC git itself has this limitation, too... ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: Policy on global variables
On Thu, Jan 16, 2014 at 1:59 AM, Eric Wong normalper...@yhbt.net wrote: This. I prefer we keep passing around the ctx variable to keep the code more flexible for future reuse. Of course, IIRC git itself has this limitation, too... Can anyone confirm or deny this? Is it a pointless endeavor because of git's design? ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
