httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: apache/linux modules
Date Mon, 02 Feb 1998 23:31:13 GMT

On Mon, 2 Feb 1998, Cristian Gafton wrote:

> On Mon, 2 Feb 1998, Rodent of Unusual Size wrote:
> > Sure.  How does it differ from "./Configure ; make"?
> > 
> > I still have grave concerns about autoconf's ability to sense all the
> > platform-specific issues src/Configure does.
> Well, it does so for squid. And for gcc. And for emacs. And for
> PostgreSQL. And for sendmail. And for bind. And for a whole plethora of
> big, large programs with heavy requirements on identifying the exact
> differences between platforms. 
> Why wouldn't it do it for apache ?! 

Because apache uses multiple co-operating processes that require
lightweight IPC and require shared network sockets.  In many cases it's
as simple as that.  For example, the following POSIX program fragment
fails on many svr4 systems:

    int s;
    int i;

    .... set up s for listening ....

    /* fork two children */
    for (i = 0; i < 2; ++i) {
	if (fork() == 0) {
	    int client = accept(s);

Many systems just don't like having multiple processes doing accept()
on the same socket.  But they don't tell you that directly, they may
not even tell you with this example.  They may only tell you that they
suck when you've got 50 children all busy serving requests.  And the
system will tell you it sucks by melting the CPU or maybe panicing.
But in no way will it tell you with an errno from accept() or other
useful thing you can automatically test.

None of the programs you list above are like Apache.  Even squid is
different -- it is a single monolithic process.  sendmail uses multiple
processes, but there is only one main process doing accept(), and there's
almost no (lightweight) IPC.

I'm not aware of any other server which uses the same model as Apache.
I'd love to be told of one though, so that we can go look and compare
our solutions.

There are certainly bugs that we can test, like the hack in make_socket()
that deals with TCP/streams lameness on solaris and other svr4 boxes
regarding SO_REUSEADDR.  I'm not denying this.  I'm just saying there
are bugs which aren't easy to test.


View raw message