Return-Path: 
 <dev-return-3272-apmail-apr-dev-archive=apr.apache.org@apr.apache.org>
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 5524 invoked by uid 500); 13 Jul 2001 00:44:43 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:dev@apr.apache.org>
List-Help: <mailto:dev-help@apr.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@apr.apache.org>
List-Subscribe: <mailto:dev-subscribe@apr.apache.org>
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 5374 invoked from network); 13 Jul 2001 00:44:39 -0000
From: "Sander Striker" <striker@apache.org>
To: "Ian Holsman" <ianh@cnet.com>,
	<dev@apr.apache.org>
Subject: RE: SMS Factory Re: cvs commit: apr/memory/unix
 apr_sms_threads.cMakefile.in
Date: Fri, 13 Jul 2001 02:53:59 +0200
Message-ID: <JLEGKKNELMHCJPNMOKHOEEBKEDAA.striker@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <994961985.28056.58.camel@c1619481-a.almda1.sfba.home.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

> would it be usefull to have some kind of 
> 'sms_factory' which you could call
> either with a identifier, or better yet, a set of capabilities it
> requires from the SMS
> (manysmallallocs, realeaseatend ) or ( bigallocs,tracking)
> 
> which could then give you the best match for your environment?

Well, at that point you already know your environment, so we might
as well create a small tool asking questions about environments.
Something like so:

Do you have lots of small allocations [y/n]? y
Do you free your malloced blocks      [y/n]? n
...

The best probable match is: <type>

Where type is "std", "tracking", "trivial", "blocks", etc.

Then you just put in a call to apr_sms_<type>_create on the spot.
Each type also may have different parameters you can give it
at create and a factory would make that more difficult.
 
> so for example the http code would, at worker creation, ask for a SMS
> (or two) and the factory would give it the best it could taking
> threading and type of allocations the caller wanted?
> 
> the idea behind this would be that you would only call this once /twice
> at startup (as it's children would be of the same type in most cases) ,
> so it shouldn't be too much of a performance hit

If it isn't dynamic, in the sense that you always create the same
type of sms given the same environment specs, it is unneccessary overhead.

Just my take on it,

Sander