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