apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: SMS as Pools Patch
Date Thu, 12 Jul 2001 09:12:15 GMT
On Wed, Jul 11, 2001 at 09:14:52AM -0700, Justin Erenkrantz wrote:
> On Wed, Jul 11, 2001 at 04:53:54PM +0200, Luke Kenneth Casson Leighton wrote:
> > how are you going to keep _users_ from _not_ using apr_sms_child_xxx
> > and friends?
> It's not exported as a function?  Only a SMS itself would see this
> function?
> > not being funny or anything, but what is a trivial mallocator
> > doing adding an extra 4096 bytes in the _first_ place?
> Well, part of it is inertia and an optimization.  The current pool 
> code adds an additional 4096 bytes to any allocation in order to 
> make any allocation of <4096 bytes be done for free since we have
> already allocated it - we just tack it on to the block that we have
> just allocated.  Dean Gaudet may have more explanation as to why we 
> do this, but the current pool code definitely does this.
thanks justin.

> The completely trivial SMS is tracking.  =)  The names all suck
> horrendously, but no one has come up with good names for our SMS.
> Trivial SMS is the closest implementation of the current pool 
> allocation system.  Tracking is the one you should be able to grasp in
> <5 minutes.
okay... can we swap the names?  [i'm serious!]

> Realistically, though my thought for the long term is to have one root 
> trivial SMS (or similar SMS with a freelist) per thread 

> and a bunch of 
> tracking SMS (brain-dumb five-minute SMS that don't do much).  I really
> think this is where we ought to be headed.  Does that need the
> child_malloc path?  Probably not.



even _with_ the existing pools system, i've been watching the
messages go back-and-forth about how pools and threads are messing
everything up [general summary, i don't have the experience of
actually _using_ this stuff :)].

so, if that's the case, then there are two problems.

one: pools in threads are messed up.

two: sms can't be developed effectively because no changes are
allowed to existing code.  and some of the solutions being proposed
involve pools and threads.

well, surely those two could be tested and developed at the
same time, yes?


0.02 Euros...


View raw message