RE: SMS Factory Re: cvs commit: apr/memory/unix apr_sms_threads.cMakefile.in

[Sander Striker <st...@apache.org>]

> 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

Re: SMS Factory Re: cvs commit: apr/memory/unix apr_sms_threads.cMakefile.in

[Luke Kenneth Casson Leighton <lk...@samba-tng.org>]

On Fri, Jul 13, 2001 at 02:53:59AM +0200, Sander Striker wrote:
> > 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.

this fits in well with having a bit-field in every SMS
[a new function]: what features do you support?

see other-post, 30mins ago.

luke