On Saturday, September 14, 2002, at 01:58 PM, Philip Martin wrote:
>
> That means that the error's debugging line number won't be useful. It
> may be better for the cancel function to return boolean and for
> SVN_ERR to generate the error. Just have the client specify a pool
> when it specifies the cancel function.
i thought of that, but it raises an interesting question. is it more
important to get the line number of where you were canceled, or to have
the user defined cancelation function be able to annotate the error
with some indication of why you were canceled? something worth
thinking about.
> Note that as far as asynchronous signals go, it doesn't really matter
> whether SVN_ERR calls the cancel function before or after expr, so it
> can be written
>
> svn_error_t *svn_err__temp = (expr);
> if (svn_cancel__func
> && svn_cancel__func (svn_cancel__baton)
> && ! (svn_err__temp && svn_err__temp->apr_err == ERR_CANCEL))
> svn_err__temp
> = svn_error_create (ERR_CANCEL, 0, svn_err__temp,
> svn_cancel__pool,
> "Drat! Foiled again!");
> if (svn_err__temp)
> return svn_err__temp;
i thought of that, but i figured since we've already been told to stop
doing work, we might as well make that check happen before we go off
and do any other work. it's probably not important one way or the
other though, and yours does seem simpler.
>> the problems of thread safety, async signal safety, and anything else
>> is conveniently pushed up into the client application, which knows
>> enough about the environment it will run in to solve it in a robust
>> manner.
>>
>> svn__cancelation_handler and svn__cancelation_baton would be declared
>> volatile,
>
> Not necessary, they only get used synchronously. The function may
> access a volatile flag when it runs, but Subversion doesn't see that.
good point.
>> and we'd require that svn_set_cancelation_handler be called
>> before any subversion function that the app wants to be able to be
>> canceled, and that it not be called while other subversion functions
>> are happening (so that svn__cancelation_handler and
>> svn__cancelation_baton don't have to be protected by a mutex).
>
> Yup.
ok, cool. i'll work up a patch using this technique later today.
-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 20:58:23 2002