httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: layered I/O (was: cvs commit: ...)
Date Wed, 29 Mar 2000 05:19:47 GMT
>> Bite me. You're being totally confrontational here, and it isn't called
>> for. You didn't read my statements. I said no change to generators, and
>> definite changes to processors.
>no it is called for.
>this item has been on the bullet list for as long as apache-2.0 has been a
>wet dream.
>there's been a fuckload of hand waving over the years, and *no code*.  
>code speaks reams more in my book than anything else.
>so far all i'm seeing is more hand waving, and cries that this isn't the
>wet dream folks thought it would be.
>welcome to reality.  if you folks would stop waving your hands and
>actually try to code it up you'd probably understand our proposed

Dean, this is crossing my tolerance threshold for bullshit.  You haven't
even looked at the code that was committed.  If you had, you would notice
that it doesn't implement IO-layering.  What it implements is IO-relaying
and an infinite handler loop.  This isn't handwaving.  The code simply
doesn't do IO-layering.  Period.

Layered-IO involves a cascaded sequence of filters that independently
operate on a continuous stream in an incremental fashion.  Relayed-IO
is a sequence of processing entities that opportunistically operate
on a unit of data to transform it to some other unit of data, which
can then be made available again to the other processing entities.
The former is called a pipe-and-filter architecture, and the latter
is called a blackboard architecture, and the major distinctions between
the two are:

   1) in layered-IO, the handlers are identified by construction
      of a data flow network, whereas in relayed-IO the handlers
      simply exist in a "bag of handlers" and each one is triggered
      based on the current data state;

   2) in layered-IO, the expectation is that the data is processed
      as a continuous stream moving through handlers, whereas in
      relayed-IO the data is operated upon in complete units and
      control is implicitly passed from one processor to the next;

   3) in layered-IO, data processing ends at the outer layer,
      whereas in relayed-IO it ends when the data reaches a special
      state of "no processing left to be done".

Yes, these two architectures are similar and can accomplish the
same tasks, but they don't have the same performance characteristics
and they don't have the same configuration interface.  And, perhaps
most significantly, relayed-IO systems are not as reliable because
it is very hard to anticipate how processing will occur and very easy
for the system to become stuck in an infinite loop.

I don't want a blackboard architecture in Apache, regardless of the
version of the release or how many users might be satisfied by the
features it can implement.  It is unreliable and hard to maintain
and adds too much latency to the response processing.  But if somebody
else really wants such an architecture, and they understand its implications,
then I won't prevent them from going with that solution -- I just
don't want them thinking it is what we meant by layered-IO.


View raw message