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 Wed, 11 Jul 2001 14:53:54 GMT
On Wed, Jul 11, 2001 at 04:32:54PM +0200, Sander Striker wrote:
> > > When one of us gets a chance, we can implement the child_malloc path in
> > > trivial.  That should remove most of the current complaints about SMS.
> >  
> > so, you want to add apr_sms_child_malloc etc. which makes
> > SMS a non-trivial API, which is one solution to the problem,
> > and the other solution is to write a better sms than
> > apr_sms_trivial.
> > 
> > one solution makes the SMS api quite complex.
> > 
> > the other keeps it simple.
> 
> 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?

> 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 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"'.

... 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?

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 :)


> > because it's very unclear [and i helped _design_ SMS, remember?]
> > and if it's unclear, i really don't think it's a good idea to
> > put it in, especially if there are other solutions.
> > 
> > basically, apr_sms_child_malloc is giving me bad vibes - warning
> > alarm bells are ringing: that's the best way i can put it.
> 
> Well, for now this is the best solution to solve the problems seen
> in apache _without_ modifying the apache codebase. It is a way to
> allow stacking of advanced memory systems in a more  acceptable
> manner when it comes to performance/waste trade-off.

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

all best,

luke

Mime
View raw message