apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: API to prevent further allocations from a pool?
Date Thu, 07 Sep 2006 15:58:01 GMT
Jeff Trawick wrote:
> Occasionally I see problems caused by Apache modules using per-process
> pools on a request processing thread.  Aside from the thread-safety
> issues, they had no business doing that anyway.
> 
> It would be cool for the MPM to be able to lock the pool once it is
> ready to start serving requests so that if any errant module tries to
> use pconf, pchild, etc. it will crash immediately instead of
> introducing memory corruption under load.  (Even if the module author
> is "clever" and uses a mutex around the pool use, that assumes she is
> the only person in the world to have that idea.)

+1 - this existed until the pool/allocator was refactored, and didn't
survive both iterations.  I'm sure the code that was trashed (entirely
demotivating me from writing it -again-) is still in history, it's not
all that difficult.  The win32 code was pretty trivial, the unix code
relied on locking an mmap which seems silly in this day and age.

There is still a call in httpd main.c...

        apr_pool_lock(pconf, 1);

        ap_run_optional_fn_retrieve();

        if (ap_mpm_run(pconf, plog, server_conf))
            break;

        apr_pool_lock(pconf, 0);

just waiting for at least some platforms to support apr_pool_lock.

Bill




Mime
View raw message