You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2001/02/22 10:25:43 UTC
Re: ThreadsPerChild - should it include the implicit signal thread?
On Thu, 22 Feb 2001, Jeff Trawick wrote:
> (threaded mpm only; no idea about perchild)
>
> ThreadsPerChild currently includes the implicit signal thread.
>
> I am -0 on it including the signal thread (i.e., I don't like that you
> get 49 worker threads when you code ThreadsPerChild=50).
>
> I raise the issue not because I feel so strongly about it but that
> there is a small bug to fix, and depending on whether or not
> ThreadsPerChild should include the signal thread the bug will be fixed
> differently.
ThreadsPerChild should NOT include the signal thread. That directive
talks about how many worker threads you have, not total threads.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: ThreadsPerChild - should it include the implicit signal thread?
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> 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.
I got it finally :)
Thanks!
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: ThreadsPerChild - should it include the implicit signal thread?
Posted by rb...@covalent.net.
On 22 Feb 2001, Jeff Trawick wrote:
> rbb@covalent.net writes:
> > On 22 Feb 2001, Jeff Trawick wrote:
> > > rbb@covalent.net 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 rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: ThreadsPerChild - should it include the implicit signal thread?
Posted by rb...@covalent.net.
> > > 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
But worker_thread should have initialized the scoreboard correctly, so
that element ap_threads_per_child - 1 does have an actual value.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: ThreadsPerChild - should it include the implicit signal thread?
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> On 22 Feb 2001, Jeff Trawick wrote:
> > rbb@covalent.net 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 :)
> > 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?
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: ThreadsPerChild - should it include the implicit signal thread?
Posted by rb...@covalent.net.
On 22 Feb 2001, Jeff Trawick wrote:
> rbb@covalent.net 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.
> 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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: ThreadsPerChild - should it include the implicit signal thread?
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net 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++) {
It was added when you started creating the signal thread, so I assumed
that your reasoning was that ThreadsPerChild includes worker threads +
signal 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.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: ThreadsPerChild - should it include the implicit signal thread?
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"William A. Rowe, Jr." wrote:
>
> I feel I've lost that argument two weeks ago. Folks want
> 'abstract' concepts so they don't have to tweak anything
> between firing up a pthread, pervhost, etc.
People test-driving the various models to see which one
works best in their particular environments would probably
have difficulty caring less about the nomenclature. They
have a goal of serving N+ concurrent requests in the most
efficient manner; they almost certain do *not* care what
the details of the various methods are. And having to
change the settings of meaninglessly-named (to them)
directives just to do the test-driving of each model.. that
is not going to be popular.
I would guess that the above describes at least 50% of the
Apache userbase.
The n models are:
1. one worker per process (prefork);
2. one worker per thread;
3. upto(N) workers in each of upto(M) processes (perchild);.
How about MaxWorkers and MaxProcesses? The latter would be
simply ignored for threaded and prefork (or maybe a warning
message for prefork if specified and different from MaxWorkers).
Do we need to actually specify a workers/process setting for
perchild? Can it not be heuristically derived from these two
settings?
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
ApacheCon 2001!
Four tracks with over 70+ sessions. Free admission to exhibits
and special events - keynote presentations by John 'maddog' Hall
and David Brin. Special thanks to our Platinum Sponsors IBM and
Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend
only Apache event designed and fully supported by the members of
the ASF. See more information and register at <http://ApacheCon.Com/>!
Re: ThreadsPerChild - should it include the implicit signal thread?
Posted by Bill Stoddard <bi...@wstoddard.com>.
----- > > On Sun, 25 Feb 2001, William A. Rowe, Jr. wrote:
> >
> > > From: "dean gaudet" <dg...@arctic.org>
> > > Sent: Sunday, February 25, 2001 6:14 PM
> > >
> > >
> > > > On Fri, 23 Feb 2001, Rodent of Unusual Size wrote:
> > > >
> > > > > Then let us call it 'WorkersPerChild,' confound it! Or whatever
> > > > > name we use for 'entity capable of serving a request'!
> > > >
> > > > +1000.
> > >
> > > Make that +1001, if we are avoiding the Thread/Process labels, then ignore
> > > the danged things. Accept in all mpms - and emit a warning that goes something
> > > like "WorkersPerChild has no effect in mpm_pthread". No vi httpd.conf required.
> >
> > hrm i'd rather the directives just not exist in mpms in which they make no
> > sense. there's no reason to maintain backwards compat with 1.3 config
> > files... and there's probably a <IfModule> incantation you can use to
> > differentiate your multiplatform config files (if any such thing even
> > exists, i can't really imagine it myself).
>
> I feel I've lost that argument two weeks ago. Folks want 'abstract' concepts so
> they don't have to tweak anything between firing up a pthread, pervhost, etc.
>
Ummm, no. I don't recall anyone advocating using the 'exact' same set of config directives across
all MPMs. The directives are all over the fsking place right now and they need some sanity applied.
It is just silly for one mpm to use 'child' thingis and another to use 'server' things another to
use 'worker' thingis and another to use 'client' thingis when they are all describing the same
thing. And I don't recall anyone advocating not using the <IfModule> block directives either. Maybe
I haven't been reading my mail.
Bill
Re: ThreadsPerChild - should it include the implicit signal thread?
Posted by rb...@covalent.net.
On Sun, 25 Feb 2001, William A. Rowe, Jr. wrote:
> From: "dean gaudet" <dg...@arctic.org>
> Sent: Sunday, February 25, 2001 6:51 PM
> > On Sun, 25 Feb 2001, William A. Rowe, Jr. wrote:
> > > From: "dean gaudet" <dg...@arctic.org>
> > > Sent: Sunday, February 25, 2001 6:14 PM
> > > > On Fri, 23 Feb 2001, Rodent of Unusual Size wrote:
> > > >
> > > > > Then let us call it 'WorkersPerChild,' confound it! Or whatever
> > > > > name we use for 'entity capable of serving a request'!
> > > >
> > > > +1000.
> > >
> > > Make that +1001, if we are avoiding the Thread/Process labels, then ignore
> > > the danged things. Accept in all mpms - and emit a warning that goes something
> > > like "WorkersPerChild has no effect in mpm_pthread". No vi httpd.conf required.
> >
> > hrm i'd rather the directives just not exist in mpms in which they make no
> > sense. there's no reason to maintain backwards compat with 1.3 config
> > files... and there's probably a <IfModule> incantation you can use to
> > differentiate your multiplatform config files (if any such thing even
> > exists, i can't really imagine it myself).
>
> I feel I've lost that argument two weeks ago. Folks want 'abstract' concepts so
> they don't have to tweak anything between firing up a pthread, pervhost, etc.
>
> Granted, advanced concepts don't belong everywhere. But if we can't agree that
> a process is a process, and a thread is a thread, and we want things more generic
> for (??? I'm still not clear), then this is probably a legitimate no-op.
>
> Agreed on 1.3 non-compatibility, disagree based on the list's take on the issue that
> we don't need to be reasonably compatible between mpm's. If the user wants to play
> advanced pervhost games, let those be in <Module > blocks.
I'm with Dean, and against the list, on this one. Stop trying to make all
the MPMs look alike. They aren't the same, and trying to make them the
same is a bad thing. I agree 100% that if a directive is in two MPMs, it
should act the same way, but do not tell me that in all MPMs, I have to
have the same directives.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: ThreadsPerChild - should it include the implicit signal thread?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "dean gaudet" <dg...@arctic.org>
Sent: Sunday, February 25, 2001 6:51 PM
> On Sun, 25 Feb 2001, William A. Rowe, Jr. wrote:
>
> > From: "dean gaudet" <dg...@arctic.org>
> > Sent: Sunday, February 25, 2001 6:14 PM
> >
> >
> > > On Fri, 23 Feb 2001, Rodent of Unusual Size wrote:
> > >
> > > > Then let us call it 'WorkersPerChild,' confound it! Or whatever
> > > > name we use for 'entity capable of serving a request'!
> > >
> > > +1000.
> >
> > Make that +1001, if we are avoiding the Thread/Process labels, then ignore
> > the danged things. Accept in all mpms - and emit a warning that goes something
> > like "WorkersPerChild has no effect in mpm_pthread". No vi httpd.conf required.
>
> hrm i'd rather the directives just not exist in mpms in which they make no
> sense. there's no reason to maintain backwards compat with 1.3 config
> files... and there's probably a <IfModule> incantation you can use to
> differentiate your multiplatform config files (if any such thing even
> exists, i can't really imagine it myself).
I feel I've lost that argument two weeks ago. Folks want 'abstract' concepts so
they don't have to tweak anything between firing up a pthread, pervhost, etc.
Granted, advanced concepts don't belong everywhere. But if we can't agree that
a process is a process, and a thread is a thread, and we want things more generic
for (??? I'm still not clear), then this is probably a legitimate no-op.
Agreed on 1.3 non-compatibility, disagree based on the list's take on the issue that
we don't need to be reasonably compatible between mpm's. If the user wants to play
advanced pervhost games, let those be in <Module > blocks.
Bill
Re: ThreadsPerChild - should it include the implicit signal thread?
Posted by dean gaudet <dg...@arctic.org>.
On Sun, 25 Feb 2001, William A. Rowe, Jr. wrote:
> From: "dean gaudet" <dg...@arctic.org>
> Sent: Sunday, February 25, 2001 6:14 PM
>
>
> > On Fri, 23 Feb 2001, Rodent of Unusual Size wrote:
> >
> > > Then let us call it 'WorkersPerChild,' confound it! Or whatever
> > > name we use for 'entity capable of serving a request'!
> >
> > +1000.
>
> Make that +1001, if we are avoiding the Thread/Process labels, then ignore
> the danged things. Accept in all mpms - and emit a warning that goes something
> like "WorkersPerChild has no effect in mpm_pthread". No vi httpd.conf required.
hrm i'd rather the directives just not exist in mpms in which they make no
sense. there's no reason to maintain backwards compat with 1.3 config
files... and there's probably a <IfModule> incantation you can use to
differentiate your multiplatform config files (if any such thing even
exists, i can't really imagine it myself).
-dean
Re: ThreadsPerChild - should it include the implicit signal thread?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "dean gaudet" <dg...@arctic.org>
Sent: Sunday, February 25, 2001 6:14 PM
> On Fri, 23 Feb 2001, Rodent of Unusual Size wrote:
>
> > Then let us call it 'WorkersPerChild,' confound it! Or whatever
> > name we use for 'entity capable of serving a request'!
>
> +1000.
Make that +1001, if we are avoiding the Thread/Process labels, then ignore
the danged things. Accept in all mpms - and emit a warning that goes something
like "WorkersPerChild has no effect in mpm_pthread". No vi httpd.conf required.
> it's 2.0, please make the configuration directives meaningful. i think i
> had an XXX or TODO or somesuch comment in the code somewhere suggesting
> this... i know it was on my mind in the MPM split -- each architecture
> could have whatever directives made the most sense.
>
> -dean
>
> p.s. isn't it a sign of the apocalypse that ken and i are in agreement?
I was just thinking something more ominous ... 2.0 must be nearing release ;-)
Re: ThreadsPerChild - should it include the implicit signal thread?
Posted by dean gaudet <dg...@arctic.org>.
On Fri, 23 Feb 2001, Rodent of Unusual Size wrote:
> Then let us call it 'WorkersPerChild,' confound it! Or whatever
> name we use for 'entity capable of serving a request'!
+1000.
it's 2.0, please make the configuration directives meaningful. i think i
had an XXX or TODO or somesuch comment in the code somewhere suggesting
this... i know it was on my mind in the MPM split -- each architecture
could have whatever directives made the most sense.
-dean
p.s. isn't it a sign of the apocalypse that ken and i are in agreement?
Re: ThreadsPerChild - should it include the implicit signal thread?
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
rbb@covalent.net wrote:
>
> ThreadsPerChild should NOT include the signal thread. That directive
> talks about how many worker threads you have, not total threads.
Then let us call it 'WorkersPerChild,' confound it! Or whatever
name we use for 'entity capable of serving a request'!
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
ApacheCon 2001!
Four tracks with over 70+ sessions. Free admission to exhibits
and special events - keynote presentations by John 'maddog' Hall
and David Brin. Special thanks to our Platinum Sponsors IBM and
Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend
only Apache event designed and fully supported by the members of
the ASF. See more information and register at <http://ApacheCon.Com/>!