> 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
worse
> > 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
cancellation
> > 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
much
> larger task, which involves touching quite a bit of code for a gain
that
> (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
way
> 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
in,
> 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.
Bill
---------------------------------------------------------------------
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