On Fri, 18 May 2001 [EMAIL PROTECTED] wrote:
> So what, this model extends to solve that problem. The child process was
> started, and it watches the scoreboard. When one of the old threads dies,
> the child process can create the new thread. This puts the onus
> completely on the child process to start itself. The parent process
> creates child processes, and then gets out of the loop until it wants to
> kill of a child process. This also automatically keeps us paying
> attention to MaxClients.
the 1.3 scoreboard method of counting the non-idle children doesn't scale
very well. it's another source of memory pressure because it means one
cpu needs to access non-local data every scoreboard maintenance interval.
that's one of the reasons SCOREBOARD_MAINTENANCE_INTERVAL is tunable on
1.3 -- i noticed improvements by increasing the interval in benchmarks
years ago.
the whole scoreboard_maintenance function is also a waste of CPU on any
machine which is not doing any web-related work... apache wakes up every
second and hauls a bunch of data back into the caches only to determine
nothing needs to be done.
> Using a linked list doesn't have that benefit.
sure it does. it's trivial to count how many active requests there are.
you don't have to go add up the non-idle states. i did a sample
implementation of this before the MPM stuff. see
<http://arctic.org/~dean/apache/2.0/select-thread-hybrid-02.tar.gz>, and
look at the file pthreads/src/main/http_event.c.
(not that i'm saying shared memory linked lists are the right solution
either, in fact i don't think shared memory is the right solution period.)
-dean
