On Sat, Sep 14, 2002 at 02:36:47AM +0200, Branko Ä?ibej wrote:
> Garrett Rooney wrote:
>
> >there are actually two states we need to worry about. the first is
> >'have we been canceled', which tells SVN_ERR and SVN_ERR_W to return
> >an SVN_ERR_CANCELED error, and the second is 'are we in the process of
> >backing out because we received a cancelation', which causes
> >svn_error_clear_all to return an SVN_ERR_CANCELED error.
>
> You only need the one state. Here's the pseudocode:
[ snip pseudocode ]
yeah, that makes sense. i've been thinking about this for the past
few hours (long car ride), and that's essentially one of the
implementations i had settled on. i think you've got a better handle
on how the locking needs to work than i did though ;-)
> Regarding the implementation of svn_err_cancel and error locations: Look
> at how the other error creation routines are implemented, and note that
> svn_error.c undefines the macro wrappers first. With this
> implementation, the SVN_ERR_CANCELLED errors will have correct location
> info (i.e., they'll come from the SVN_ERR macros). It would make sense
> to create a location wrapper for svn_error_clear_all, too; and note that
> you should pass the incoming error to svn_error_create_all, so that we
> don't get duplicate SVN_ERR_CANCELLED errors.
this hasn't quite clicked yet, but i'll reread it in the morning. i'm
sure it will be more clear when i'm actually looking at the code
anyway.
one more fundamental question has occured to me though. do we want to
say that this cancelation causes ALL threads currently executing
subversion code to cancel? if so, it seems to me that it's only going
to be good for implementing signal handlers, which is fine for us, but
bad for other clients. i can easily envision a GUI client which wants
to provide the ability for the user to cancel a long running svn
function call, and if we do it like this, then that would have the
effect of canceling ALL running svn functions. that certainly doesn't
seem like a friendly API to code to in my opinion.
i think i have a way of solving this solution, but i'm not sure it's
feasable. as i suggested before, we could allow the client app to
register its own cancelation callback, which would be called out of
SVN_ERR to determine if the function has been canceled. if the client
app wants to do something more complex than the simple 'stop it all
now' type implementation we're going to use for the command line
client, they could do so reasonably easily. for example, if they're
going to have multiple threads calling subversion code simultaneously,
they just have to save the id's of those threads and the cancelation
status of each thread in some data structure somewhere, and their
cancelation callback does the equivalent of pthread_self() and looks
up it's own cancelation status. to cancel a particular thread, you
just set it's flag in that data structure. in this type of interface,
the svn_async_cancel and svn_async_reset functions would not exist as
part of the svn API, rather they would be implemented by the client
app (svn_cl__async_cancel or something like that). the only issue i
see with this is that the client's handler has to be pretty fast,
since it's going to get called every time we have an SVN_ERR, and a
client that tries to do something fancy could get themselves into
performance trouble.
so is it worth the extra complexity (versus the algorithm branko
presented above) to allow the client the ability to specify a more
complicated cancelation scheme?
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 14 05:31:11 2002