httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Moving things around
Date Tue, 09 May 2000 23:33:55 GMT
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 :) ))

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.

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 :)

> 
> ok fine.  here's one of my usual requests:
> 
> give me a use case.
> 
> demonstrate to me a need for a multiprocess webserver to support threads
> (created by modules) within each process.
> 
> until someone does that we're all talking out our asses.
> 
> it's not sufficient to say "someone might want to do it".  i want to hear
> what the application is, and i want to hear reasons why it should be
> solved in such an assinine way.
> 

Some of the best things have been invented because "someone might want
to do it." Now if it makes life hell, then, yeah, we might need more
reasons, but what is so objectionable about APR having support for
threads, but Apache simply using a prefork MPM? And saying "well, if
they have threads, they should USE it" I don't think is valid enough :) :)

And the issue is more than just "threads". It's how APR fits in. I
see it as an generic application library layer, which provides a
consistant application interface to functionality, while insulating
the application from the nasty details about how it's implemented.
A nasty example is that almost no application makes use of the entire
stdio/sfio suite, but all those functions are there because someone
might need them...

But maybe I _am_ just talking outta me arse :)

Cheers!
-- 
===========================================================================
   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
                "Are you suggesting coconuts migrate??"

Mime
View raw message