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 as Pools Patch
Date Wed, 11 Jul 2001 14:32:54 GMT
> > 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).

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

> luke


View raw message