httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: Anywhere to go for a summmary of I/O filtering?
Date Tue, 25 Jul 2000 09:07:17 GMT
On Mon, Jul 24, 2000 at 09:18:21AM -0700, wrote:
> Filtering does a lot more than just SSL or mod_include processing
> CGIs.  Filters allow us to simplify the entire server, remove some hacks,
> and get a really cool proxy.

Do we plan to introduce these benefits for 2.0?

> This will be tough to do.  How many modules does use that
> haven't been ported to 2.0?  Remember, you have to look at more than just
>, you have to look at *, because those are all
> just virtual hosts.

Once 2.0 mod_proxy is ready :), we could ProxyPass a 1.3 server for
all the modules that haven't been ported. We could also run all images
off of a 2.0 server running off of a seperate port or something.

> On Mon, 24 Jul 2000, Bill Stoddard wrote:
> > Apache 3.0 requirements....
> > filtering
> > async i/o
> > per process User/Group assignment
> > integrated mod_ssl (perhaps even in 2.0 if the legal climate is agreeable)
> Ever notice that we just keep pushing those same requirements down to the
> next release?  These are the exact same things that we said were going to
> be in 2.0 a couple of years ago.

Well, a few have been knocked off the list. I don't think anyone would
advocate doing any of the tough parts above for 2.0.

> > async i/o and filtering will have a significant anount of design
> > interdependence, so doing one without the other is not wise, IMHO.
> While I agree that async I/O would be cool, it isn't portable
> currently.  If we really want to write an async server, we will need to be
> very careful about how it is done.  This will not be a fast
> process.  Delaying filtering until we can write an async server is not a
> good idea IMNSHO.  That would give us filtering in two or three years.

I'm actually thinking supporting async and non-blocking I/O won't be
too hard. I'm thinking a threaded server, each thread running a
two-layer event-driven state machine. The non-blocking case does both
layers of state machine, the async case does only the
read->write->read->write state machine layer, and the
thread-per-connection case just follows the states in order. This will
require seperate MPMs, and probably can't be APRized so easily, but I
think it can be done in Apache.

I'm being purposefully terse and obtuse because we're not doing async
yet; it's not time to slow down 2.0 development for this. I'll try to
write something up in a few months when 2.0 is stabilizing more.

Anyway, my only point when talking about the relationship between
async and filtering is that it would be nice if 2.0 went out the door.
Filtering is not in 2.0 yet. Lots of code and design will end up being
trashed for 3.0 anyway. Greg did raise a reasonable point about
getting the experience from filtering to use in future versions, but
that can be said for any new big, complicated feature.

One of the reasons that people want to throw features to 2.0 is that
releases take so long. This is a constant problem on the linux-kernel
list too, so maybe this is futile, but after 2.0, it'd be nice to try
to peg a short list of showstopper features that should go into the
next release. Other features wouldn't be rejected, but they wouldn't
become release showstoppers without a vote.

View raw message