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