> From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
>
> Bill Tutt wrote:
> >
> >>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.
>
> FWIW, the fact that a GUI client might have more complex needs than
the
> command line client is the reason the proposed solution uses a client
> specified callback. the previous proposals had just a simple volatile
> sig_atomic_t with a 'svn_async_cancel' function that would twiddle it.
> then SVN_ERR would check that variable. this would ONLY be useful for
a
> signal handler type situation (or a single threaded client app), which
> was why i pushed for the callback. this way if the client has more
> complex needs, they can provide a callback function which takes that
> into account. they still have to go through a single callback
function,
> but it is certainly possible to write that function to handle a
complex
> multithreaded app.
>
Callbacks are useful, but the application needs the ability to have a
finer grained approach for handling cancellation batons. Given how often
this cancellation callback is called we should design the API so that
the Subversion/user application interface is as efficient as possible.
If the application supplied callback needs to be thread safe and acquire
synchronization objects in order to do its work because it has to mesh
between a thread aware and a non-thread aware state of existence then
you're substantially penalizing the performance of the user application
with this design.
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:07:44 2002