You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Laurie <be...@gonzo.ben.algroup.co.uk> on 1996/01/16 11:00:40 UTC

Protocol Abstraction - where we're at...

Following discussions of the Apache Protocol Abstraction API, David Robinson
and I have reached the following tentative conclusions:

1. Multithreading _must_ be optional (too many systems do not support it).

2. Multiple processes are not a satisfactory substitute for multithreading (too
much overhead) in all cases, but may be required for some (e.g. HTTP-NG).

3. The model for the abstraction should be similar to that of STREAMS, that is,
boxes ("modules" in STREAMS terminology) are pushed onto a stack through which
all I/O is channeled. I/O is classified into types, so as data progresses
through the stack it gets more thoroughly digested (for example, you read raw
data and pass upwards a lump of headers and a lump of "body" data).

4. There are essentially two variations on this theme. In the first, everything
"knows" when it is appropriate to read or write, and simply does so at the
correct moments. In the other reads and writes are asynchronous, and are
dealt with as they arise.

5. Further work is impeded by the current structure of Apache w.r.t. file
descriptors.

------------------------

Now, I know this isn't much to go on, but we feel we cannot be any more
specific without first doing some experiments.

I would like to take a minor step towards the abstraction in order to simplify
the carrying out of these experiments. This step is to clean up the existing
abstraction (which revolves around a request) - there are some places where
the abstraction is not used, and to remove direct dependencies on file
descriptors. I'm confident that these changes can be made without serious
damage to Apache.

The point about doing this to the mainline Apache, rather than the experimental
ones is that this change is required no matter how you think abstraction works,
so doing it first avoids considerable duplication of effort, as well as making
it easier to keep the experimental versions up to date.

Cheers,

Ben.

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant        Fax:   +44 (181) 994 6472
and Technical Director      Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant        Fax:   +44 (181) 994 6472
and Technical Director      Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.