On Wed, Jun 06, 2001 at 05:35:43PM -0700, Justin Erenkrantz wrote: > On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote: > > This isn't possible with pools. They limit you to a single way of getting > > at your memory regardless of how it was obtained. > > What I basically said in my email to David was that I could see having a > pool take in an option as to which SMS it should use. I've said this > before a few weeks ago (probably when I first looked at the SMS code), > but let me reiterate that suggestion. Obviously, there would be a > default SMS that would be used, if one isn't provided when the pool is > created. > > I think that this allows the SMS code to be kept simple, while the pool > code can be kept relatively similar to what it does now. > > I'll shut up for a while on this. -- justin
:) perhaps i should re-iterate / confirm that what justin says, above, is exactly how i envisioned SMS to be used. more than that, it can even be hidden behind apr_initialise(). the initial call to create the initial pool does not even need to _take_ an extra sms argument: by _default_ the existing apr_pool_create() function just... uses the standard-memory sms. now, if you don't _want_ a pool that use the standard-memory sms, you call, uh... say, apr_pool_create_from_sms() - which is what justin above recommends be actually called apr_pool_create(). i'll shut up too because i'm probably confusing matters by not exactly knowing the total internal workings of apr. yet. luke
