Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Wed, 10 May 2000 10:12:17 -0700 (PDT)
From: dean gaudet <dgaudet-list-new-httpd@arctic.org>
To: new-httpd@apache.org
Subject: Re: Moving things around
In-Reply-To: <200005092333.TAA00535@devsys.jaguNET.com>
Message-ID: <Pine.LNX.4.21.0005101004590.8362-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Tue, 9 May 2000, Jim Jagielski wrote:

> dean gaudet wrote:
> > 
> OK, but of course the argument can be made that this is a "manufactured"
> case, since the beastie doesn't exist (but again, we're talking
> about providing capability to cover those situations which we _can't_
> think of right now (yes, I know, that's a cop out :) ))

that is a total cop out, and completely unacceptable for engineering a
system.  if we can't think of them then the application does not exist --
we're a bunch of bright people with a lot of experience in this
application realm.  that's why i ask for use cases.

> Doesn't fastcgi spawn an Apache child process to handle fastcgi
> requests? Why should we restrict the fastcgi daemon from not running
> threads, simply because we want a prefork MPM? It's certainly much
> better for fastcgi to be able to utilize threads if it's available,
> no matter what MPM is used to spawn-off that initial process.

so fastcgi spawns another process which execs the fastcgi program which
spawns threads.  has nothing to do with APR.  in fact, the fastcgi program
could use APR in its threaded incarnation.  it already communicates via a
socketpair() or similar... they've already done the work of modularizing
the code.

and then you don't have to worry about how you combine multiprocess
libraries with multithreaded libraries.

of course you guys might like trying to figure out how to link together
the most perverse combination of libraries... but i want you to say that
:)  i personally think most of this configuration crap we go through
w.r.t. compile-line options is because we do something dumb:  we attempt
to accomodate every single library within the same process space.

this is not good engineering.

> Anyway, it's all like someone saying to the Wright Brothers "OK,
> give me a use case." The impression I've been getting from module
> writers on the list is that _they_ would like it, which seems
> good enough for me :)

bad example, the wright brothers had a use case:  we want to travel
through the air from point A to point B.

> Some of the best things have been invented because "someone might want
> to do it."

really?  someone might want to do *what* ?  that's what i'm asking.  i
don't deny someone might want to do *it*, i'm just asking what *it*
is.

i see exactly two possibilities for using a threaded APR within a
multiprocess MPM:

- an extra process forked off the parent which wants to use threads.  this
is your fastcgi example, and as i've already demonstrated does not require
the APR linked with the MPM to be multithreaded.  utilize
modularity: fork/exec another process space.

- extra threads spawned within each process:  this causes an N-fold
increase in the number of threading objects, which generally won't scale.  
it's far better to architect either a multithreaded MPM, or architect
another server to sit beside your HTTP process.

-dean