On Sat, Feb 05, 2011 at 05:15:22PM +0100, Stefan Küng wrote:
> On 05.02.2011 16:46, Stefan Sperling wrote:
> >What if the amount of information requested simply doesn't fit
> >into memory? I'd prefer a system that cannot fail in this way.
> >I'd prefer passing the information to the client piece by piece,
> >and letting the client worry about where to store it.
> >If at all possible, the library shouldn't allocate huge slabs of
> >memory outside of the client's control.
>
> Sure, that would be the ideal way. But if it's not possible to force
> clients to behave and if that's a requirement, allocating a lot of
> memory might be the only alternative.
The other alternative that's being considered is to run per-directory
queries in the compat code. Then we can invoke callbacks once per
directory, outside of an sqlite transaction context, so that callbacks
written for 1.6.x an earlier cannot cause deadlocks on the DB.
This might mean that code compiled against 1.6.x runs a bit slower
against 1.7. libraries. But it will still run and function correctly.
The amount of memory allocated would be a function of the contents of
one directory (vs. the content of an entire working copy...)
> >How is your query any different from the new proplist API and
> >implementation I added in r1039808? I think that provides what you need
> >(for the proplist case). It opens the db, runs a query on it and streams
> >the results to the client via a callback. Very low overhead.
>
> Haven't tried that proplist API. I just reviewed it and it really is
> what I need. Too bad it got reverted. I hope it will get put back in
> soon.
I hope to be able to put it back in.
I would like to rev all affected callbacks, and document what they're
not allowed to do. If a callback behaves improperly, the entire working
copy can deadlock. Maybe we can even try to detect deadlocks and error
out (see http://svn.haxx.se/dev/archive-2011-01/0219.shtml).
This is really a design problem for the most part.
Implementing it is fairly simple once we've decided what we want to do.
It's nice to know that TortoiseSVN would be happy with this approach.
Stefan
Received on 2011-02-05 17:54:19 CET