[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 18:36:18 CEST

Bill Tutt wrote:

> No it doesn't. If the last patch I submitted it didn't contain it, it's
> clearly quite easy to just pass in the cancellation callback, and baton
> to every appropriate entry point that needs to construct and compose the
> cancellation editor. (Assuming you want to use the cancellation editor.)

good point.

> I don't care so much about using the cancellation editor approach. I
> care more about providing the ability to specify more than one
> cancellation baton. Being able to specify more than one callback
> function would be nice too, but applications can work around that more
> easily than by not being able to specify more than one cancellation
> baton.

unfortunately, having multiple cancelation batons means that we can't
just stick this check inside SVN_ERR, we'd actually have to insert calls
to the cancelation callback all over the code. in many cases a
cancelation editor could take care of this, but probably not all of them.

do we want to go down this road? i mean how much worse off is it for
the client applications if they have to work with a single baton? how
common is the 'i have multiple different threads all doing subversion
stuff at the same time' case, and will working with a single
callback/baton be a huge penalty for them? it means adding a couple of
locks inside the callback, but how expensive is that really? i'd
personally be willing to go with the current implementation we've got
until someone can show us a concrete example of it being a horrible
speed problem.


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