httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Maintenance of mod_proxy and async i/o
Date Sun, 30 Apr 2000 01:42:55 GMT
> Hrm... I actually proposed something very similar a few weeks ago! (I had
> been thinking in terms of a front-end, reverse proxy approach, keeping
> this "buffer" process distinct from the Apache process(es), but closely
> integrated.)

Yes, I'm familiar with your posts :-).

> There are a lot of questions to be answered about the overall design
> before starting coding, I think, but this is definitely something I'd want
> to look at. What sort of ideas do you have for this so far??

I think I laid it out somewhat well in my original post.  But
anyhow..., what I'm thinking of is a slight alteration.  Something
like mod_asyncio.  During module initialization it would spin out a
thread for any other apache module/core that wanted to use it for
reads/writes.  This module would take the fd where data was to be
read/written off of, and a pointer to some memory/mmap'd file for it
to put it's stuff in.  (How/were storage takes place is a place I'd
like input on?  iovecs, mmaped files for larger content, and what
should be the amount of input rule on this?)  I think reads could be
worked on later, but I'm going to start working on writes next week.
Mod_proxy could plug into this functionality, as could any other
module that wanted to use a faster way to push collect bits.

There probably needs to be a good bit of discussion for reads..., my
ideas on are rather insane I have to admit.  But the writes are fairly
straight forward.  Apache puts together the response like normal, and
then sets the ownership of the fd to the asyncio thread, then the
asyncio thread takes care of sending it out.  (also notifies the
thread about where it can find the data, and in what form via a enum
or something)

Originally I had thought of incorporating this all into mod_proxy but
Doug of mod_perl replied rather cryptically that he had some interest
in this... so I'm thinking a generic module might be better.


View raw message