Re: permissions (and other) problems

Branko ÄŒibej <brane@xbc.nu> writes:

I hadn't considered the pool problem, I think we may need to get the
application to register the cancellation pool first.

>
>
> You only need the one state. Here's the pseudocode:
>
> # global state
> apr_atomic_t svn_cancelled = false

svn_cancelled should be volatile (on a Unix or POSIX system anyway).
The way the Subversion code is arranged it may well work without being
volatile, but we should do it properly.

> apr_mutex_t svn_cancellation_mutex

I'm not sure we need, or can use, a mutex.

> apr_pool_t *svn_cancellation_pool = null
>
> # public interfaces
> def svn_async_cancel(pool):
> svn_cancellation_mutex.lock()

Is apr_mutex_t.lock async-signal safe? The POSIX pthread functions
are not async-signal safe. Does APR provide stronger guarantees than
the POSIX pthread functions? While pthread_mutex_lock may be
async-signal safe on some platforms, relying on that doesn't look
right.

> apr_atoomic_set(svn_canceled, true)
> if svn_cancellation_pool is not null:
> svn_cancellation_pool = pool;
> pool.register_cleanup(lamba x: *x = null, &svn_cancellation_pool)
> svn_cancellation_mutex.unlock()

I'd do something like

void svn_async_pool_initialize (apr_pool_t *pool)
{
   svn_cancellation_pool = pool;
}

void svn_async_cancel (void)
{
   svn_cancelled = TRUE;
}

void svn_async_clear (void)
{
   svn_cancelled = FALSE;
}

svn_boolean_t svn_async_is_cancelled (void)
{
   return svn_cancelled;
}

The rest as per Brane's mail.

The application must call svn_async_pool_initialize if it is going to
use svn_async_cancel. Once svn_async_cancel is called the application
must wait for all threads to return from Subversion functions before
calling svn_async_clear. If you want to add error checking in
svn_async_cancel then on a POSIX system write (not stdio) and _exit
are async-signal safe

   if (! svn_cancellation_pool)
     {
       write (stderr, message, sizeof (message));
       _exit();
     }

If the application wants to do fancy mutex stuff in it's signal handler
then it gets to decide how portable it is. Subversion should restrict
itself to things that are known to work.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org