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 08:05:18 GMT
On Wed, Jul 11, 2001 at 06:48:29PM +0200, Sander Striker wrote:

> >> 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.
okay... such as?

... and is this a slippery slope?

first, we have user allocations.  then we have child sms allocations.
then there is ... grandchild sms allocations?  then, maybe,
faster sms allocations?  then, maybe... sms allocations that
are going to be a massive-repeat-loop on realloc, later [sander knows
why this is: i'll explain it briefly, here.  DCE/RPC function call
transfers are split up into Protocol Data Unit sizes of a typically
negotiated size of 0x1630 - 5680 - bytes.  there is no limit on
the *actual* amount of data that is transferred, and i'm not
joking about that.  NT has a hard-limit of 5megabytes but in
practice, services tend to terminate with prejudice if you go
above 1mb.  you therefore receive potentially hundreds of 0x1630
byte data blocks, and you have to strip out the first 16 bytes
and chain the rest together...]

in other words, would it be better to have an extra parameter to
the malloc to indicate what the sms should do?  advice to the
sms as to the _type_ of alllocation being performed?

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

okay, i buy that.

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

okay... urr...  so... again, you're second-guessing the
capabilities of the parent-mallocator (in this case,
malloc, via the default-sms.

or, is the parent-mallocator another apr_[misnamed:)_trivial?

because if it's an apr_sms_trivial, then your speedup is
_actually_ achieved by avoiding problems in another part of,
or the usage of, apr_sms_trivial.

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

this really does sound to me like there is a problem
with stacking a trivial on top of a trivial, and that
the proposed solution is to make this a special case
to deal with what is effectively a broken situation.

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

... how about a #define that makes apr_pool_create call a
new function that does what you need, especially if what
you need is the same in every place [exactly what, you haven't
explained, so i don't know :) ]

sorry to be so stick-in-the-mud, my friend, esp. on-list.
it's important to me that there are good reasons for things :)

all best,


View raw message