httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: 3.0 - Proposed Requirements
Date Wed, 14 Feb 2007 20:36:08 GMT
Paul Querna 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.
> 
> Proposed Requirements:
> - C99 Compiler.

-.9 - what does it win us over todays requirements?

> - High Performance Event System Calls (KQueue, Event Ports, EPoll, I/O
> Completion Ports).

-1 - no way as a baseline.  Great if you have em, the modules should
remain oblivious, the mpm and underlying apr support should solve it.

> - Async Socket and Disk IO available. (POSIX AIO?)

-1 for the same reason as above.  We can provide every module author
the abstract appearance that their socket/disk IO is all async even
if it isn't.

> - Good Kernel Threading.
> 
> Based on this list, the following operating systems would be supported
> TODAY:
> - FreeBSD >= 6.x
> - Solaris >= 10
> - Linux >= 2.6
> - Windows >= XP? (Maybe even 2003 or Vista -- I don't know this one well
> enough)

This is the only one I'll bend on... I'm beginning to thing it is the
long-term solution to use threads-not-processes as baseline, even if
you want a one thread per process model.  All modules should behave as
if they are in the threaded async model, of course.

> Operating systems that would likely have problems with these
> requirements today:
> - AIX?
> - NetWare?
> - HP-UX?
> - Many other older Unixy systems.

Not your problem, drop this.

My point is that we can make this appear to be an entirely async,
preemptively multithreaded and even fiber-based design without actually
requiring any of these if their MPM is much simpler.

In 3.0

> The key part to me for all of these is this is Today.  If you view any
> 3.0 project on a 1-3 year timeline, if we start pushing things like high
> performance event system calls, there is time for these other operating
> systems to pick them up.

If you set a three year timeframe it won't happen.  If you set a one year
timeframe without better resolution of "what" it won't happen.

Chop this up into manageable pieces and get hacking :)

> Today, we have all of the major platforms with a good level of async IO,
> events and threading support, so it makes sense to me to set these are
> the base requirements.

The day you have the first accepted non-2.3'ish patch, we'll fork the
trunk to it's own branch for 2.x dev, give you 2.9.0 on trunk, and just
let everyone code away to either.  As you hint, another 2.some release
is likely before 3.n is ready.

Bill

Mime
View raw message