apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: [POLL] pools, apr 2.x, and beyond
Date Wed, 12 Oct 2005 15:08:53 GMT
   Ah yes, I was thinking in terms of memory allocation within a third
party application rather than APR's own internal memory use.  Makes more
sense now.


>>> On 10/11/2005 at 2:55:35 pm, in message
"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
>>>       strategies, allowing support of non-pool based apr
>> What more would the latter bring to the table that couldn't already
>> 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.
> Bill

View raw message