apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: SMS Factory Re: cvs commit: apr/memory/unix apr_sms_threads.cMakefile.in
Date Fri, 13 Jul 2001 00:53:59 GMT
> 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


Mime
View raw message