On 22 Feb 2001, Jeff Trawick wrote:
> [EMAIL PROTECTED] writes:
> > On 22 Feb 2001, Jeff Trawick wrote:
> > > [EMAIL PROTECTED] writes:
> > >
> > > > ThreadsPerChild should NOT include the signal thread. That directive
> > > > talks about how many worker threads you have, not total threads.
> > >
> > > Okay, I'm glad we're on the same page!
> > >
> > > What is the explanation for the " - 1" in the next expression which
> > > controls how many threads we create in the new child?
> > >
> > > for (i=0; i < ap_threads_per_child - 1; i++) {
> >
> > Previously, we created ap_threads_per_child threads, and the original
> > thread became the signal thread. With the new logic, we create a separate
> > thread for the signal thread, so the original thread becomes one of the
> > worker threads. The -1 is so that we don't create ThreadsPerChild +1
> > threads on startup.
>
> to my eyes this is a direct contradiction of your previous post in
> this thread :)
Nope. We want to create ThreadsPerChild threads to serve pages.
Previously, we did:
for 1 to ap_threads_per_child
create_thread(worker_thread)
handle_signals
Now we do:
create_thread(handle_singnals)
for 1 to ap_threads_per_child -1
create_thread(worker_thread)
worker_thread
If we don't have the -1, then we will have created 1 too many worker
threads.
> > > Besides not starting enough worker threads per child, the scoreboard
> > > maintenance is also confused because the SERVER_DEAD entry
> > > (uninitialized) in the slot for thread ap_threads_per_child-1 keeps it
> > > from counting the threads of that child in the number of idle threads.
> >
> > I don't really understand this, because worker_thread should have just
> > handled all of this stuff.
>
> the problem is pretty simple:
>
> only creating ap_threads_per_child-1 worker threads means we only use
> elements 0..ap_threads_per_child-2 of the scoreboard array for this
> child; idle-server-maintenance logic looks in elements
> 0..ap_threads_per_child-1 of the scoreboard array for each child; when
> it finds any element which has the uninitialized/SERVER_DEAD value
> then bad stuff happens (like not counting any of the idle threads in
> that child towards the number of overall idle threads); thus bad stuff
> happens since element [ap_threads_per_child-1] is uninitialized
>
> It seems cleanest to let ap_threads_per_child be the number of worker
> threads. Otherwise, we have a scoreboard entry which multiple pieces
> of code needs to know to ignore. Also, does the admin really want to
> bother thinking about the thread which is lost to signal handling?
This is what is happening. We are creating the correct number of threads
right now.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
