On Fri, Mar 16, 2007 at 04:12:17PM CET, Johannes Schindelin wrote:
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html