On 10/11/05, 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.
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. -garrett
