> From: Philip Martin [mailto:philip@codematters.co.uk]
>
> "Bill Tutt" <rassilon@lyra.org> writes:
>
> > > Which cancellation editor? Is there some mechanism already in
place?
> > > Grepping the source code for "cancel" doesn't reveal anything.
> >
> > Once upon a time, (dunno if the code is still there), I had
submitted a
> > patch for a cancellation editor that got composed with the update
and
> > commit editors. This allowed per operation cancellation baton state
to
> > be used and leveraged.
>
> I don't see anything obvious in the current code. I have found some
> patches in the mailing list from about nine months ago, a combined
> trace/cancel set, I guess they never made it into the code base.
>
That wouldn't surprise me. :(
> > > > Doing it this way lets the user application maintain its state
> however
> > > > it wants, and not in some bizarre way that's necessitated by
> > > > Subversion's API choice.
> > > >
> > > > It just so happens that the command line client doesn't care so
much,
> > > > but other more sophisticated users of the API might.
> > >
> > > It also happens to be fairly simple to implement. I'm not sure
how a
> > > general cancellation mechanism would work, but I suspect it may
> > > involve passing some sort of context baton through every
subversion
> > > function. That may not be a bad thing to do anyway; I'm wondering
it
> > > it would be a better approach to the access baton stuff.
>
> From a quick browse through the patches it seems that it would allow
> the application to cancel at each editor function. That does not
> introduce as many cancellation points as Garrett's patch, but it may
> be enough.
The cancellation editor idea was to try and provide a tradeoff between
always calling the cancellation callback everywhere, and trying to
ensure that the cancellation callback got called before every possibly
expensive network touching operation. (i.e. mostly trying to ensure that
a multi-threaded UI could have a chance in cancellation the current
operation in progress)
> A few places would not allow cancellation, post-commit
> processing for example, I don't know if that's a problem. I suppose
> it depends on exactly how many operations fit into the cancellation
> editor scheme: what about transmitting postfix text deltas during a
> commit, or receiving a large file during an update?
>
If you're canceling a commit, then we don't care where the cancellation
happens. Post-commit processing should be asynchronous anyway. The user
application shouldn't be able to cancel post-commit processing except
from within the post-commit processing code.
> > > What sort of thing do you see a sophisticated API user doing when
it
> > > repsonds to an asynchronous signal?
> >
> > The user API might have multiple Subversion operation contexts
because
> > the GUI is multi-threaded. One thread for user directed requests,
and
> > another for background communication requests to lazily update the
UI
> > every so often.
> >
> > The UI might very well want to have different cancellation baton
data
> > for each UI context.
>
> Well, the approach in Garrett's patch does allow an application to
> cancel on the basis of thread identity, and if the application tracks
> which operation each thread is running it can decide which threads to
> cancel.
>
At the cost of a bunch of synchronizing objects for each call into the
cancellation object. Ick...
> The cancellation editor approach fits in neatly with the other editor
> code. I wonder how much bit-rot your patches have suffered over the
> months? I think the trace part is redundant, but the cancel part may
> be worth investigating.
Got me. I don't really care about the cancellation editor continuing to
exist as I wrote it originally. I just want Subversion's public API to
support the ability of the user application to supply multiple
cancellation batons.
If you use an updated version of the patch, great, if not I don't care.
Just give our API users the ability to pass in multiple cancellation
batons.
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 17:25:38 2002