using APR read/write locks

[Evgueni Brevnov <ev...@gmail.com>]

Hello,

I'm experiencing problems using APR read/write locks on Windows.
Namely, the problem arises when I've destroyed a read/write lock and
trying to destroy the pool where the lock was allocated. Here is a
simple test:

#include "apr_general.h"                                    // line 1
#include "apr_pools.h"                                       // line 2
#include "apr_thread_rwlock.h"                           // line 3

int main() {                                                        // line 5
    apr_pool_t * pool = NULL;                              // line 6
    apr_thread_rwlock_t * rwlock = NULL;             // line 7

    apr_pool_initialize();                                       // line 9
    apr_pool_create(&pool, NULL);                       // line 11
    apr_thread_rwlock_create(&rwlock, pool);        // line 12

    apr_thread_rwlock_destroy(rwlock);                // line 14
    apr_pool_destroy(pool); // <---CRASH HERE   // line 15
    return 0;                                                       // line16
}                                                                      // line17

The problem shows it self when debugging in Microsoft .NET developer
environment. The reason of the failure is an attempt to call "BOOL
CloseHandle(HANDLE hObject);" function twice for single event. MSDN
says: "Closing an invalid handle raises an exception when the
application is running under a debugger. This includes closing a
handle twice…". After some investigations I found out that
apr_thread_rwlock_destroy doesn't remove cleanup callbacks from the
associated memory pool. Thus CloseHandle is called first time in line
14 when we destroy lock and then later in line 15 as a result of
executing registered cleanup callbacks while destroying memory pool.
What do you think about the proposed fix for the problem (see attach)?

Thank you
Evgueni Brevnov, Intel Middleware Products Division

Re: using APR read/write locks

[Garrett Rooney <ro...@electricjellyfish.net>]

On 1/17/06, Evgueni Brevnov <ev...@gmail.com> wrote:

> What do you think about the proposed fix for the problem (see attach)?

Looks good to me, committed to trunk in r371172.

-garrett