> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
> 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.
*/
Sander