httpd-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.

--Brian




Mime
View raw message