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
