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