> We have hit an impass in my mind. Dean and I are saying that having each
> thread have it's own pool is a requirement. Not just for httpd, but for
> anything using pools. Dean, if I am mis-interpreting you, then I am
> sorry, and please correct me.
>
> Aaron, you disagree. you want each app to make that decision on their
> own. I see no way to implement that in a thread-safe manner.
(Just as a side note, I don't remember seeing anything refuting the technical
aspects of such an implementation. I would be interested in one, of course,
if you think it is infeasible.)
> So, I would suggest that we approach this problem in another way. My ONLY
> goal for APR is to make a library that is useful for cross-platform
> development and eases the pain of cross-platform development for
> developers. That was the goal when I created APR, and my original test
> case was the Apache web server.
>
> 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.
In my mind, there are really only two major points that need addressing:
- Optionally creating a child-pool for each thread. This provides us two
things in my mind:
1) Allowing the application to choose an SMS for this thread-pool (which
could very well be a special SMS created just for this purpose).
2) Allowing an application to refrain from creating a child-pool.
- Like you [Ryan] said, it is a problem that the thread creation routines
right now are not advertising the pool to the thread itself. This to
me can be corrected with a better API. The two things I've brought up
here are:
1) void * worker_fn(void *opaque_data) should have an additional
pool param.
2) apr_thread_exit() is unacceptable. It currently requires a
apr_thread_t structure. I would be happy if either the worker_fn was
extended to pass in the apr_thread_t OR if we could architect a way
for apr_thread_exit() to not need the apr_thread_t struct.
I have a feeling the second point will be more palatable, and as such
I'll volunteer to cook up a patch illustrating these changes.
As for the first point, which is the reason this thread has been going on
so long, I'm willing to compromise on the idea of forcefully creating
a childpool always, if it necessary, merely because I see it only as
overhead for some applications, but not a functional defect.
-aaron
