Garrett Rooney <rooneg@isris.pair.com> writes:
> something like this might solve the problem:
>
> typedef svn_error_t * (*svn_cancelation_handler_t) (void *cancel_baton);
>
> void svn_set_cancelation_handler (svn_cancelation_handler_t cancel_handler,
> void *cancel_baton);
>
> then SVN_ERR is something like:
>
> #define SVN_ERR(expr) \
> do { \
> svn_error_t *svn_err__temp = SVN_NO_ERROR; \
> if (svn__cancelation_handler) \
> { \
> svn_err__tmp = svn__cancelation_handler (svn__cancelation_baton); \
> if (svn_err__tmp) \
> return svn_err__tmp; \
> } \
> svn_err__temp = (expr); \
> if (svn_err__temp) \
> return svn_err__temp; \
> } while (0)
>
> (with similar things happening in SVN_ERR_W and svn_error_clear_all)
>
> the client app's cancelation handler is responsible for creating the
> SVN_ERR_CANCELED error, out of a pool in it's cancelation baton.
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.
typedef svn_boolean_t (*svn_cancel_func_t) (void *cancel_baton);
void svn_set_cancel_func (svn_cancel_func_t cancel_func,
void *cancel_baton,
apr_pool_t *cancel_pool);
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;
>
> 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.
> 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.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 14 19:59:21 2002