"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.
> > > 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. 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?
> > 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.
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.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 18 16:19:50 2002