httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject Re: 3.0 - Proposed Requirements
Date Wed, 14 Feb 2007 12:14:46 GMT
On 2/14/07, Paul Querna <chip@force-elite.com> wrote:
> This proposed list of requirements for a 3.0 platform. this list enables
> a 'base' level of performance and design decisions to be made. If others
> can make designs work with 'lessor' requirements, all the better, but
> I'm not worried about it.

I'm not sure what that means.  Other than perhaps the C99 stuff, I
think we all take it for granted that the design should take proper
advantage of the other features when available.  So the topic for
discussion is an absolute set of requirements, with the implementation
not complicated by logic to support a lower set of system
requirements.  Either we design it to require fancy features to work
at all or we don't.

>
> Proposed Requirements:
> - C99 Compiler.

shrug (for some reason it seems more natural to me to follow APR on
what language level is required)

> - High Performance Event System Calls (KQueue, Event Ports, EPoll, I/O
> Completion Ports).
> - Async Socket and Disk IO available. (POSIX AIO?)

Designing the server so that it can take advantage of these when
available but work fine without them is of tremendous value, not only
for supporting older or different platforms but also for providing a
simplified debugging/development environment for logic not directly
tied to these features.

I don't think we should force every module author to have to be aware
of these aspects of the design (though they may have to require the
use of a simpler MPM).  And we don't want to keep 2.x healthy forever
or chase people to other web servers.

> - Good Kernel Threading.

Dealing with threads/no-threads definitely introduces clutter.  Some
new Apache helper functions that are no-ops when !APR_HAS_THREADS or
the MPM has a single threaded process serving requests could clean up
a lot of the code that cares about this, perhaps at a very slight
performance cost for the non-threaded builds.

Mime
View raw message