httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: alloc_mutex, spawn_mutex cleaned up too soon
Date Fri, 24 Mar 2000 21:59:36 GMT
OK. Here's a slight "wrinkle". Up to now, we've required an ANSI
compiler, but NOT full ANSI functions. atexit() is ANSI. Now
gcc can be compiled to create atexit in it's library for the
compiler, but it's not done by default I think. There are also
other versions of this floating around I think...

Just a simple FYI, nothing more than that.

Greg Stein wrote:
> 
> +1 on all accounts. This is the Right Thing, notwithstanding Ryan's mental
> block :-)
> 
> Good structure, and good modularization. Nice job!
> 
> Cheers,
> -g
> 
> On Fri, 24 Mar 2000, Jeff Trawick wrote:
> 
> > > > . make the APR app call something like ap_term_alloc()
> > > >   before biting the dust
> > > 
> > > This is the most symmetric solution, so I like it. We could use
> > > atexit() to force this to happen as well.
> > 
> > I think I changed my mind on that one ;)  ap_init_alloc() is
> > called as a side-effect of calling ap_create_context() the first
> > time.  The app doesn't actually call ap_init_alloc().
> > 
> > What I will try is this (in case somebody wants to comment before
> > I show the code):
> > 
> >   Existing function ap_initialize() will call internal APR function
> >   ap_init_alloc().  That will do most of what current ap_init_alloc()
> >   does now, but ap_make_sub_pool(NULL,NULL) will not be called until 
> >   the first context is requested (later, if ever by this app).  Cleanup
> >   of the locks will not be registered with any pool.  The return code 
> >   of ap_init_alloc() will be ap_status_t, like ap_initialize().
> > 
> >   New function ap_terminate() will call new internal APR function
> >   ap_term_alloc(), which will clean up the locks (if multithreaded).
> > 
> > I like the idea of using atexit(), but currently http_main() is 
> > careful (?) to call destroy_and_exit_process() and in there
> > call ap_destroy_pool().  If we trust that, then we can trust calling
> > ap_terminate() from there.  If we ever change our minds, then we can
> > call destroy_and_exit_process() (perhaps with a changed name) via
> > atexit().  The app, not APR, owns the problem of stacking the
> > atexit() routines properly (probably the natural order would work
> > fine though).
> > 
> > -- 
> > Jeff Trawick | (too many addresses, most without a j)
> > 
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 


-- 
===========================================================================
   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
                "Are you suggesting coconuts migrate??"

Mime
View raw message