Date: Thu, 11 Jul 1996 11:27:16 -0700 (PDT)
From: Alexei Kosut <akosut@organic.com>
To: new-httpd@hyperreal.com
Subject: Re: Configurable nph filenames
In-Reply-To: <199607111813.OAA01657@hershey.ai.mit.edu>
Message-ID: <Pine.SOL.3.93.960711111954.29833A-100000@acidik.organic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

On Thu, 11 Jul 1996, Robert S. Thau wrote:

> Hmmm... I would have thought another way of addressing this problem
> would be just to thread the server (which means only one copy of
> configuration info, etc., rather than one per transaction).  If we're
> going threaded anyway over the long term, then NPH- provides a kludge
> to get around the problem in the meantime, and given the potential
> back-compatibility problems with it, I'm not sure it's for the best
> to create another.

I agree. As for threading...

http://hyperreal.com/httpd/httpd/project-plan.html has threading in 2.0,
with a 1.2 in the middle which has a bunch of little-to-medium sized
project.

I've been thinking about this, and I see no reason why we can't skip the
1.2 step and move directly to 2.0 as our next release. Most of the
feature-level enhacements in the '1.2' batch can be worked on concurrently
with threading and autoconfiscation, which are the major things in 2.0.
And I see no reason to artificially postpone work on them just to release
1.2 first - if we remember history, 1.1 was released five months later
than we originally had planned, because we kept adding more stuff. The
same thing will no doubt happen with 1.2.

I once worked on a software project with a couple other people. This
software was a real RAM hog, and slow to boot, so one of us (not me) sat
down and started to rewrite the thing, completely. He almost finished,
too, but in the meantime, the rest of us kept adding stuff to the working
version, and so the rewritten version, which was much improved, never got
finished. I envision the same thing happening to a threaded Apache.

I think some people may be under the impression that threading Apache is
somehow difficult, or unportable, or something that needs a lot of work. I
don't think so. RST has already done all the hard work of writing a
threading package, almost entirely in ANSI C. As I understand it, it will
work already on 95% of Unix systems, and the rest can be ported to easily
with a half dozen lines of OS-specific code. 

I say we move the development version to a threaded server immediately. I
know others agree with me. Can we put it to a vote or something, so we can
at least get a clear idea of where we're going, and how better to get
there?

-- Alexei Kosut <akosut@organic.com>            The Apache HTTP Server 
   http://www.nueva.pvt.k12.ca.us/~akosut/      http://www.apache.org/