On Fri, Mar 16, 2007 at 04:12:17PM CET, Johannes Schindelin wrote: > Hi, > > [please do not cull the Cc: list] > > On Fri, 16 Mar 2007, Rocco Rutte wrote: > > > First, I think that would be some cleanup "only" since that basically would > > mean to > > > > 1) make all functions die()ing return some value and handle it and > > 2) wrap all static vars into structures and pass them around > > > > If you don't choose a design before wrapping things up in structures, you'll > > probably end up having one structure per source file (at least too many > > structures). > > Why? For some tasks, it should be 1) easier, 2) more elegant, and 3) > faster to write a function which re-initialises the static variables. > > Of course, if you want to work with multiple repos _at the same time_, > this does not help you. But frankly, we don't support that with core-git, > so why should we in libgit? Because you don't know who will want to use libgit. Maybe perl bindings from inside of mod_perl, where single process can multiplex between many repositories based on whichever request just arrived. You talked about memory usage issues, but I think that's just a minor technical issue that can be adjusted, while this is _conceptual_. Maybe someone will want to write repodiff which looks at two repositories and compares them (without fetching massive data around). Maybe someone will want to write some other cool hack we didn't think about. Because in the other subthread you just suggested the git viewers should be multi-threaded. Of course you can state that "only a single thread can use libgit at a time", but then multithreading is just a hack to work around libgit limitations (albeit still legitimate) while it could be used to do so much more cool stuff like fetching old history information on background while you can already _work_ with the tool and look at the new stuff details (isn't this actually exactly how gitk and qgit already work? they couldn't with non-reentrant libgit!). Because if you look at the UNIX history, you'll notice that first people started with non-reentrant stuff because it was "good enough" and then came back later and added reentrant versions anyway. Let's learn from history. It's question of probability but it's very likely this will happen to us as well. This is why the _API_ should be designed to be re-entrant. The implementation may not be re-entrant right away, it may take a while to get there, but the API really should be. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Ever try. Ever fail. No matter. // Try again. Fail again. Fail better. -- Samuel Beckett - 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