httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject Re: Event MPM
Date Tue, 02 Nov 2004 16:12:48 GMT
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


Mime
View raw message