httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: ThreadsPerChild - should it include the implicit signal thread?
Date Mon, 26 Feb 2001 01:02:56 GMT
From: "dean gaudet" <dgaudet-list-new-httpd@arctic.org>
Sent: Sunday, February 25, 2001 6:51 PM


> On Sun, 25 Feb 2001, William A. Rowe, Jr. wrote:
> 
> > From: "dean gaudet" <dgaudet-list-new-httpd@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


Mime
View raw message