Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 8 Jun 2001 14:35:04 -0700
From: "Roy T. Fielding" <fielding@ebuilt.com>
To: David Reid <dreid@jetnet.co.uk>
Cc: APR Development List <dev@apr.apache.org>
Subject: Re: cvs commit: apr/threadproc/unix thread.c
Message-ID: <20010608143504.C965@waka.ebuilt.net>
Mail-Followup-To: "Roy T. Fielding" <fielding@ebuilt.com>,
	David Reid <dreid@jetnet.co.uk>,
	APR Development List <dev@apr.apache.org>
References: <JLEGKKNELMHCJPNMOKHOKEKDDPAA.striker@samba-tng.org>
 <00f601c0eee7$86a39f20$7f00a8c0@VAIO>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13-current-20010115i
In-Reply-To: <00f601c0eee7$86a39f20$7f00a8c0@VAIO>;
 from dreid@jetnet.co.uk on Thu, Jun 07, 2001 at 01:19:27AM +0100

On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote:
> We could implement pool using sms but we'd loose a great deal of flexibility
> and a great opportunity to make APR even more useful.
> 
> Pools are a single way of dealing with handing out memory.  they imply a
> degree of overhead and while they work eveyrwhere there is some degree of
> agreement that they're overkill in a lot of cases.  So why do it?

Argh!  I also thought that the purpose of SMS was to replace malloc/free
and not pools.  If you want to replace pools, then the code should not
be called apr_sms_blah.  Pool is the name for our memory system -- pool
does not, and never has, defined the type of memory behind it.

The current pool code is completely screwed for threaded environments
because of the mutex locks.  httpd 2.0 will not be production ready on
threaded servers until we can get rid of that locking within worker pools.
If the solution to that is to replace pools with sms, then let's get
to it, but we should do so without creating a new sms namespace.
Just use the same names as apr_pool.c and selectively compile one or
the other.

....Roy