httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: filtered I/O memory from stack or pools.
Date Thu, 01 Jun 2000 00:27:22 GMT
On Wed, 31 May 2000, Jeff Trawick wrote:
> > From: rbb@covalent.net
> > Date: Wed, 31 May 2000 16:55:48 -0700 (PDT)
> > 
> > I personally would rather see us allocating memory from pools than on the
> > stack.  If we use recursion of any kind in the filtered I/O design, then
> > we are going to be allocating on the stack.  
> 
> Yes, with recursion we'll have more stack frames allocated at once
> than with a non-recursive design.
> 
> You seem to be assuming that an 8K buffer will be in the stack frame
> of each filter just because we're using recursion.  I don't think
> there is any reason to assume that. 
> 
> 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.
> 
> (I'm not convinced that recursion is extremely important, but I find
> it natural and I don't think the storage argument holds.)
> 
> 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 :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



Mime
View raw message