> From: Philip Martin [mailto:philip@codematters.co.uk]
>
> "Bill Tutt" <rassilon@lyra.org> writes:
>
> > Oh yeah, and what are you thinking having only one user cancellation
> > handler?
> > i.e. Why is this state global?
>
> The simple answer is that it handles a global condition, namely an
> asynchronous signal.
No, it doesn't. The user of it might only need a global condition, but
it's incorrect of an API to assume that it's really a global condition.
The command line client's use of the API is a global use of course, esp.
since logic gets invoked via a signal handler, but that doesn't mean
that another user application would do the same thing.
> > There was a good reason that the cancellation editor was written,
it's
> > so that the cancellation handler could be specified for each
particular
> > and interesting operation.
>
> 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.
> > 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.
>
> 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.
FYI,
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 15:22:03 2002