[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: permissions (and other) problems

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-09-14 19:58:39 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.