apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: [POLL] pools, apr 2.x, and beyond
Date Tue, 11 Oct 2005 21:01:10 GMT
On 10/11/05, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> Brad Nicholes wrote:
> >
> >>  [ X]  Improve (al la apr_prealloc) the pool API, but continue to
> >>        use a pool-based schema for apr's resources.
> >>
> >>  [ ]  Add apr_Xalloc/_Xrealloc/_Xfree based on alternate allocation
> >>       strategies, allowing support of non-pool based apr resources.
> >
> > What more would the latter bring to the table that couldn't already be
> > accomplished through malloc(), realloc() and free()?
> In as much as apr objects need to be allocated somewhere, take for
> example apr_file_open.  It returns a pointer to a new apr_file_t.
> What's that allocated in?  Choosing the first implies that all apr
> structures continue to be pool-allocated, choosing the second would
> imply that apr structures themselves could be alloc/free'd.

One idea I had tossed around with Paul was that instead of a pool you
pass in an "allocator object" of some sort.  If that allocation object
is a pool it allocates the file and sets up cleanups as we currently
expect it to.  If not, you are responsible for using a publicly
declared cleanup function to destroy the file object.


View raw message