apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded
Date Tue, 17 Jul 2001 16:35:16 GMT
William A. Rowe, Jr. wrote:

>From: <rbb@covalent.net>
>Sent: Tuesday, July 17, 2001 11:13 AM
>>I believe that the problem is that the threaded code is creating the
>>pool, and not advertising it to the thread itself.  This is an easy thing
>>to fix.  I do not agree that every APR app that uses threads should have
>>to create their own thread pools.  That is wasted effort by every APR app.
>>I would like to see a conclusion to this thread quickly.  So, could people
>>please post their desires quickly, and what they want to see from this.
>thread-local pools would be a nice improvement, perhaps as an argument to
>apr_thread_create.  They can be flagged such that they avoid locking their own
>own allocations (of course their 'parent' allocator, malloc, or the parent
>free-list management, may still need to lock based on platform and so forth). 
>But _unless_ they remain rooted to the top level pool, in apr_process_create 
>they become orphaned, and their cleanups are never executed.  That isn't workable.
I'm not sure that the alternative is workable, either.

At the time of the fork, when the child process gets a snapshot of
the parent's memory, it's possible that some thread other than the one
invoking fork could be halfway through registering a new resource (e.g.,
file descriptor) in its pool.  There's no guarantee that it's safe to
attempt a cleanup of that other thread's pool in the child process;
if the fork has caught the data structures in an intermediate state,
attempting to destroy that pool might yield a segv.


View raw message