[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: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2002-09-18 20:53:11 CEST

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. 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 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.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 18 20:53:55 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.