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.
Brad >>> On 10/11/2005 at 2:55:35 pm, in message <[EMAIL PROTECTED]>, "William A. Rowe, Jr." <[EMAIL PROTECTED]> 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. > > Bill
