William A. Rowe, Jr. wrote:
Someone cried wolf, b.t.w., about connection and request pool
allocation being too tightly coupled to threads. They can be
decoupled pretty painlessly, by tying an allocator to a single
connection object. We can presume that request pools will be a subpool of each connection. Note - there are usually more connections than actual worker threads.
They are already decoupled. About all that the event MPM is doing with pools is passing the ptrans pool in the new state structure. Even that is probably unnecessary - c->pool should work just as well (warning: untested theory). When the connection ends, the event MPM recycles ptrans like worker does.
I had a number of memory leaks back in April - May and had to learn about how the allocators behave. I've paged out many of the details since but I believe there is a one-to-one relationship between ptrans/connection pools and allocators.
The bucket allocators were more work. They are being carried around in the state structure too, but that may be suboptimal.
Also note, clever httpd-2.0 tricks like mtmalloc can't work under this model.
I believe you, but don't see mtmalloc in either my httpd-2.0 or -2.1 trees. Since Paul's patch depends on epoll or kqueue for now, we have some other work to do before it runs on Solaris.
Greg
