apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: unix/thread_mutex.c 1.19 and --enable-pool-debug=yes core dump
Date Fri, 22 Aug 2003 14:00:16 GMT
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Friday, August 22, 2003 8:20 AM

> My thought is that the existing code is resilient enough without any
> cas logic; but I have been waiting for others to take the time to prove
> that to themselves before we back down to simple inc/dec/assignment.
> My other question - why is it necessary to explicitly use nested locks
> within the pool code?  Do we have a nesting issue that could be fixed
> and return to more optimal 'default' thread mutexes for pools?

This only for the pools debug code.  From apr_pool_create_ex_debug:

        /* No matter what the creation flags say, always create
         * a lock.  Without it integrity_check and apr_pool_num_bytes
         * blow up (because they traverse pools child lists that
         * possibly belong to another thread, in combination with
         * the pool having no lock).  However, this might actually
         * hide problems like creating a child pool of a pool
         * belonging to another thread.


View raw message