httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: filtered I/O memory from stack or pools.
Date Thu, 01 Jun 2000 00:17:23 GMT
> 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?

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message