[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Cancelling Subversion operations

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-09-18 21:55:01 CEST

> From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
> Philip Martin wrote:
> > Garrett Rooney <rooneg@electricjellyfish.net> writes:
> >
> >
> >>it means adding a couple
> >>of locks inside the callback, but how expensive is that really?
> >
> >
> > An uncontested mutex, while not free, can be cheap. The problem is
> > that it becomes expensive when contested, and it generally gets
> > as the number of threads contesting it increases.
> >
> > Bill has raised a valid point, a single callback/baton is OK as a
> > simple async-signal handling mechanism, but as a general
> > mechanism it's a poor solution.
> i agree it isn't a great solution, but it's a solution and it's here
> now. i started working on this for one reason: i want to be able to
> hit control-c when accessing a local repository without wedging the
> database.

Isn't this because we aren't talking to the datastore properly in the
first place? Our database should NEVER get wedged. I thought we'd talked
about how to fix this. We should work on that rather than this approach.
If we're not willing to tackle that work item for 1.0 then I begin to
wonder about what skewed ideas people might have about how
stable/reliable a 1.0 relase of Subversion should be.

> branko proposed a reasonably easy way to do this, so i took
> it on. to do so in a way that is the end-all be-all solution is a
> larger task, which involves touching quite a bit of code for a gain
> (at this point) is pretty theoretical.

If you could refresh my aging brain on why the database gets wedged and
why we're not addressing that before doing things this way I'd greatly
appreciate it.

> if someone else is willing to take on the task of doing this via the
> bill suggests (passing callbacks and batons down into each and ever
> function we want to allow cancelation in and inserting either
> cancelation editors or manual calling of the callback throughout the
> code), and is willing to commit to getting it done before 1.0, then
> fine, but if nobody's going to do that, i think this patch should go
> since at least it solves the immediate problem, and it even provides
> (albeit not especially well) a way to solve more complex problems.

If you'd be so kind as to reintegrate the cancellation editor then my
objections about this approach would disappear completely. That way
multi-threaded UIs can have what they want, and the command client can
have what it wants.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 18 21:55:38 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.