apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: cvs commit: apr/threadproc/unix thread.c
Date Thu, 07 Jun 2001 13:30:20 GMT
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


Mime
View raw message