httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: My oh my
Date Fri, 21 Apr 2000 12:11:23 GMT
> 
> On Thu, 20 Apr 2000, Jeff Trawick wrote:
> 
> > > This makes me want to hurl.
> > > 
> > > >
> > > >   else {
> > > >        const char *errstr;
> > > >        SYS_ERR_STRING(statcode - APR_OS_START_SYSERR, p);
> > > >        return errstr;
> > > >    }
> > 
> > The macro isn't very neat, but what makes me hurl are the storage management
> > implications on platforms where APR will need to allocate storage from
> > p.  For an APR app like Apache, it isn't a big deal because most pools
> > are short-lived.  I don't like the idea that I can't write an APR app
> > which lives forever which writes log messages from time to time unless
> > I artificially create and destroy a pool so that I don't suffer from a
> > storage leak.
> 
> welcome to one of my major complaints regarding APR using pools
> ubiquitously.  pools are excellent for some uses, and suck for lots of
> others.
> 
> > Can I pass NULL for the pool and then free() the string when I'm done?
> 
> why not pass in "char *buf, size_t bufsize" ?
> 

That is exactly how I prefer it (and how I have implemented it at least
twice :) ).

I'm with you, but I felt the unfortunate need to backtrack from my
original position to something that at least allocated storage
deterministically so that an application *could* manage what happened
when calling ap_strerror().

> malloc is dumb too for many things because it requires you to grab a
> semaphore in a multithreaded program (unless you use hoard).  whereas
> "char *buf, size_t bufsize" means it's trivial to plop it on your stack.
> 
> stack allocations come "for free" almost all the time -- they happen
> during the prologue to the function, and are all grouped into one
> subtraction from the stack pointer; and similarly during the epilogues.  
> 
> only time a stack array isn't free is if it is the only variable in the
> function that causes a stack frame to be required -- but you frequently
> get away with no stack frame only in leaf functions... which something
> calling strerror certainly isn't.
> 
> -dean

These issues will come up again when I (or somebody else) fixes the leak in
ap_poll() -- how big of a struct pollfd to allow to live on the stack
and what to do otherwise (hopefully malloc and chain to ap_pollfd_t,
reallocating as needed).  I would declare an array in autodata of 30
or so elements and use that when possible (9x% of the time).

> 
> 


-- 
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