httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: filtered I/O memory from stack or pools.
Date Thu, 01 Jun 2000 00:32:28 GMT

> > I would guess that each filter would have some persistent storage
> > (from the request's pool), including a buffer -- regardless of whether
> > or not recursion is used.  If a filter doesn't have to modify the
> > input, the same input goes to the next filter (no buffer on
> > stackframe, no copy).  If a filter has to modify the input, the new
> > version gets built in a buffer allocated from the pool.  What we would
> > have in each stackframe would be register save areas, temporaries,
> > local variables, but no big buffers.  A bunch of recursive filter
> > calls wouldn't chew up much stack.
> >
> > Where did I go astray with this?
> 
> I don't believe that you have.
> 
> I've never had the opinion that the link-based design implied that buffers
> had to be on the stack. Quite the contrary.
> 
> And depth? Just how many output filters do we truly believe will be in
> operation at any given time? I'll shoot for one scenario, and let people
> insert some more stages where possible:
> 
> 0) content-generator: produces a PHP script
> 1) layer: PHP filter, products SHTML
> 2) layer: SHTML pulls in a few #exec and #include files, producing HTML
> 3) layer: header/footer is appended
> 4) layer: gzip compression is performed
> 5) layer: chunking is performed
> 6) write to the socket
> 
> How much stack do these use? Who knows. A few hundred bytes? A thousand? I
> didn't know we were into conserving stack depth :-)

Okay, that's one area where I misunderstood the design then.  They way the
code looks to me, anytime we modify the data, we will need to pass it down
the stack.  Especially since it is possible for the data as passed to
ap_rwrite to be const'ed data.  If we write everything in one big buffer
(again the way the psued-code looks to me), this does imply big stack
usage.  I'll need to review the psuedo code again tomorrow.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message