apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject Re: API to prevent further allocations from a pool?
Date Fri, 08 Sep 2006 13:48:58 GMT
On 9/8/06, Joe Orton <jorton@redhat.com> wrote:
> On Fri, Sep 08, 2006 at 08:09:35AM -0400, Jeff Trawick wrote:
> > On 9/8/06, Joe Orton <jorton@redhat.com> wrote:
> >
> > >But to make a strong API guarantee I think this would need to use atomic
> > >operations anyway, which means the performance hit (mutexes on some
> > >platforms) would indeed be way too high for the pool allocation critical
> > >path, I think.
> >
> > I don't see the need for thread-safety here, though perhaps we're
> > thinking of two different things.  (apr_pool_freeze() may be a better
> > name for what I'm thinking of.)
>
> That makes sense; those names are definitely good too.  But the question
> remains on why this needs to go in the "production" code not just the
> debug build.  This is certainly a more intrusive feature than _join,
> which has been happily consigned to the _DEBUG build forever.  (for some
> definition of forever which includes its legacy in 1.3 anyway ;)

In my case, I see memory corruption problems only with somebody else's
production environment, which often has third-party code loaded which
I don't have access to, and as long as there is no noticeable
performance hit I'd like to be able to rule out certain common
blunders as the cause of the corruption.

Even with all of your own code, aliasing of pool pointer names within
the application and code paths that only execute under rare
configurations may make it impractical to find all such misuses by
inspection.

If there is a noticeable performance hit, then I agree that it
shouldn't be activated in the default build.  But lumping it into the
existing pool debug settings may be too drastic.

Mime
View raw message