Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
From: "Sander Striker" <striker@apache.org>
To: "Luke Kenneth Casson Leighton" <lkcl@samba-tng.org>
Cc: "APR Development List" <dev@apr.apache.org>
Subject: RE: SMS as Pools Patch
Date: Wed, 11 Jul 2001 18:48:29 +0200
Message-ID: <JLEGKKNELMHCJPNMOKHOMEOMECAA.striker@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20010711165354.G570@angua.rince.de>
Importance: Normal

>> The exported API to userland will not change (see below).
>  
> ack.  okay.  makes me happier.
> 
>>> i know that there have been message flying back/forth.
>>> i don't understand them.
>>> 
>>> please do me a favour: could you write up a clear explanation
>>> of exactly what the purpose of apr_sms_child_malloc is?
>> 
>> Ah, ok. The implementation of an sms calls apr_sms_child_malloc
>> instead of apr_sms_malloc when it wants memory from its parent.
> 
> .... okay... why?

Because there are situations where we would like to treat allocations
from a child sms different than from a user.
 
>> The same goes for calloc and free. These xxx_child_xxx functions
>> will _not_ be exported outside the SMS code space.
> 
>> The xxx_child_xxx functions can be optionally present in an
>> sms to make a distinction between a user asking memory or a
>> child sms requesting memory. 
> 
> this is the bit that makes me nervous.
> 
> it makes sms more complex to program to, to use, and to understand.
> 
> how are you going to keep _users_ from _not_ using apr_sms_child_xxx
> and friends?

By not exporting the apr_sms_child_xxx API. These functions are only
available through the sms_private.h file.
 
> > By default the framework will
> > use the malloc_fn, if a child_malloc_fn is present it will
> > use this. This allows us to handle child sms allocations
> > differently, hereby for example not letting the trivial
> > sms add the extra 4096 bytes on the alloc each time the
> > child requests 8192 bytes.
>   
> .... urrr...
> 
> not being funny or anything, but what is a trivial mallocator
> doing adding an extra 4096 bytes in the _first_ place?
> 
> doesn't sound very trivial to me!
>
> trivial to me says 'this is really simple.  it works, it
> probably stinks, we don't care: it proves the point,
> it's proof-of-concept, you can get to grips with it
> in under 5 minutes, and if you want more complex stuff
> that Does A Better Job, well... tough!  go use or write
> something else that isn't "trivial"'.

Ah, the naming issue :)
I raised that a couple of times before commiting, and noone as
of yet has come up with a better name. I started out writing
an allocator that did fairly trivial stuff internally and so
I called it trivial. Trivial can be described as pools morphed
into sms now. For the naming issues go back a few weeks :)
 
> .... but leaving that issue aside, _why_ is the trivial_malloc
> 'rounding up' the sizes to the nearest min_block size?
> 
> that implies that you are second-guessing the parent
> mallocator's ability to manage memory, and maybe
> even screwing _up_ the parent mallocator's ability
> to manage memory!  in fact, that's exactly what's happening!
> 
> we _know_ that malloc and free are pretty efficient on
> most operating systems.  so why not rely on that
> efficiency instead of trying to second-guess it and
> round-up the malloc-block sizes?

Because we most definitely get a significant speedup by 
allocating more mem than the user asks for, so we can serve
the next request from our own block. We always ask for
min_free bytes more (4096 bytes) than the user asks for,
at a minimum of min_alloc (8192 bytes).

In case of the patch we get a stack where "trivial" is the
child of another "trivial". We now have the child sms asking
for mem for the parent, which adds the 4k bytes etc.
We can circumvent this behaviour by doing the
apr_sms_child_malloc and friends implementation. The only thing
that changes is that the sms implementor has to type
apr_sms_child_malloc(parent, self, size) instead of
apr_sms_malloc(parent, size);

> btw, i'm quite happy to be told that i really don't
> get this, and to have things [im]patiently explained
> to me so i shut up :)

[...]
> surely there are better ways to do this that can be investigated
> _before_ expanding the SMS API into a more complex system?

Maybe... :)
But that involves changes to the httpd codebase which is not an
option with both pools and pools == sms should work. It will be
numerous #ifdefs in the httpd code (at the location of every
apr_pool_create) if we go down that road.

Sander