[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:41:20 CEST

> From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
> Bill Tutt wrote:
> > No it doesn't. If the last patch I submitted it didn't contain it,
> > clearly quite easy to just pass in the cancellation callback, and
> > to every appropriate entry point that needs to construct and compose
> > cancellation editor. (Assuming you want to use the cancellation
> 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
> > 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
> to the cancelation callback all over the code. in many cases a
> cancelation editor could take care of this, but probably not all of

Are there any that a cancellation editor wouldn't hit that we'd really
care about?

> 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
> locks inside the callback, but how expensive is that really?

Very. It effects every SVN_ERR location. This significantly increases
the probability of increasing the likely hood of needing to acquire a
read lock on the shared cancellation baton structure. Read locks on
arrays of data don't come for free, esp. if the application can't use
thread local storage. (e.g. on Linux, etc..)

The penalty will vary depending on the implementation of the
applications synchronization code.

The main point being that we're suddenly executing far more code then
just the simple "check and return" metaphor that we have if you have
multiple batons being used. Talk about screwing over L2 cache space and
more fun CPU pipeline stalls. Ick.


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:41:54 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.