[PATCH] apr_pool_owner_set

[jacob lewallen <jl...@cs.ucr.edu>]

	This is in reference to my previous e-mail regarding Solaris and an EOF 
when reading from apr_proc_create'd processes. I narrowed this down to 
another problem I had experienced with apr_thread_exit.

There are a few places where we're doing things to pools from threads 
who don't "own" the given pool, thereby causing the 
apr_pool_check_integrity to fail horrible when debugging. For example, 
in apr_thread_exit (we call apr_pool_destroy on the pool we created in 
apr_pool_create) Another example is in apr_proc_create, where we call 
apr_pool_cleanup_kill to remove some apr_file_t cleanups.

I checked the docs and at one point there seemed to have been the desire 
to include an apr_pool_owner_set (just grep, it's only mentioned once in 
the source) So here's a patch that implements the apr_pool_owner_set 
function and places calls to fix the above mentioned problems. The 
reason for the EOF was such that the child process would simply abort 
(with no messages because stdout and such had been redirected) Things 
worked fine under Linux because of the way thread ID's are assigned, I 
would guess. Fire away.

--
jacob lewallen
jlewalle@cs.ucr.edu

RE: [PATCH] apr_pool_owner_set

[Sander Striker <st...@apache.org>]

> From: jacob lewallen [mailto:jlewalle@cs.ucr.edu]
> Sent: Thursday, July 10, 2003 7:29 PM

Hi,

> 	This is in reference to my previous e-mail regarding Solaris and an EOF 
> when reading from apr_proc_create'd processes. I narrowed this down to 
> another problem I had experienced with apr_thread_exit.
> 
> There are a few places where we're doing things to pools from threads 
> who don't "own" the given pool, thereby causing the 
> apr_pool_check_integrity to fail horrible when debugging. For example, 
> in apr_thread_exit (we call apr_pool_destroy on the pool we created in 
> apr_pool_create) Another example is in apr_proc_create, where we call 
> apr_pool_cleanup_kill to remove some apr_file_t cleanups.
> 
> I checked the docs and at one point there seemed to have been the desire 
> to include an apr_pool_owner_set (just grep, it's only mentioned once in 
> the source) So here's a patch that implements the apr_pool_owner_set 
> function and places calls to fix the above mentioned problems. The 
> reason for the EOF was such that the child process would simply abort 
> (with no messages because stdout and such had been redirected) Things 
> worked fine under Linux because of the way thread ID's are assigned, I 
> would guess. Fire away.

Your patch is on my stack.  I'll get to is as soon as I can.  Thanks.


Sander