Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 6 Jun 2001 20:15:46 -0700
From: Greg Stein <gstein@lyra.org>
To: APR Development List <dev@apr.apache.org>
Subject: SMS stuff (was: Re: cvs commit: apr/threadproc/unix thread.c)
Message-ID: <20010606201546.M23560@lyra.org>
Mail-Followup-To: APR Development List <dev@apr.apache.org>
References: <JLEGKKNELMHCJPNMOKHOKEKDDPAA.striker@samba-tng.org>
 <00f601c0eee7$86a39f20$7f00a8c0@VAIO> <20010606173543.T14056@ebuilt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <20010606173543.T14056@ebuilt.com>;
 from jerenkrantz@ebuilt.com on Wed, Jun 06, 2001 at 05:35:43PM -0700

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

All right. This has to stop.

David, Sander: bring your conversations onto THIS list. You cannot continue
to have conversations in private, develop code in the public APR(UTIL) tree,
and then expect us to /not/ participate (review, vote, tweak, patch).

The SMS stuff is in APR now, so we are all involved. Keeping conversations
private is simply going to keep these disconnects happening in the future.

At the moment, we have a big group of people who see SMS as a substrate for
pools. However, there is a smaller group (David and Sander) who see SMS as
the end-goal, replacing pools, and that pools will eventually go away.

How did this disconnect happen? Because you guys talked in private, rather
than with the rest of the group.

</rant>

> 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.

Exactly. This was my thought, too, so seeing a pool go *inside* of an SMS
system is whacky.

>...
> IMHO, using APR without something that implements cleanup routines (like
> what the pool does now) is going to be troublesome to implement without
> rearchitecting the guts of APR.

Right on the money. APR is built around pools. There is no reason to even
attempt to believe that it will be built any other way for a while. APR 2.0
could have a different system, but for the next year... we're using pools.

----

David said that SMS gives us flexibility that pools don't have. He suggests
a few things:

> You want a single block of long lived memory, great use the standard
> allocator.
> You want high performance, low footprint memory, use a pool like system.
> You want simple shared memory, use a shared meory sms.
> You want higher performance shared meory, use a tracking sms as a child of a
> shared sms.
> etc etc

Single block of long-lived memory: the global pool (or some other long-lived
pool)

High perf: use a pool

Simple shared memory: a pool which uses a shared memory SMS for allocating
its memory.

High perf: already have it


For the few times when we need to alloc/free at a granular level, then
apr_pool_create() / apr_pool_destroy() are more than sufficient.

I am not seeing a large justification for transforming the entire APR
library (and bubbling that up into Apache, Subversion, etc). The SMS
alternative systems seem to be able to fit under the pool abstraction.


Now, it is abundantly clear that a few of us are seeing it this way. What we
don't understand is what forces it to go the other way? Why does SMS need to
be the top-level abstraction? A simple explanation here would go a long ways.

For example, "you simple cannot do <X> with a pool, but you do it <THIS> way
with SMS."

Point out that requirement, and you can change a lot of minds here. But
until then, I think you'll continue to see confused/concerned people, not
understanding why you are suggesting we toss all of the memory management in
APR in favor of SMS.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/