You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Sander Striker <st...@samba-tng.org> on 2001/06/23 01:39:21 UTC

Sms, another module

Hi all, [or all who are interested in sms :)]

The couple of weeks I've been working on a new
sms I blunty named 'trivial'. I think though that
a quick glance at the code will not enlighten
everyone, so another name is welcome.

I've attached the code for review, and will
commit as-is next week, if noone comes up with
a better name. For now I'll refer to it as
the trivial sms.

This sms is highly inspired on the way pools
work. I looked at the pools code at a detailed
level and decided to have a go at molding it
into an sms. The first thing I ran into was
the global free list the pools use. Since smss
are supposed to be hierachial, this was not
an option. Instead, each instance of the trivial
sms maintains its own free list. To keep the
memory use in check I added a limit to the
ammount of memory a sms may hold on to.
Then I came across the fact that there is no
apr_pfree() function. Ofcourse this is not
a problem if you never have to use it, but
in order to have a (long living) trivial sms
to be a the parent of another sms it needs
a free function. [to see why, consult the
sourcecode].

I've tested the trivial sms using Davids testmem
and I must say that I am pleased with the results.
Currently we get about the same results as the
pools code (without locking). Sometimes its faster,
sometimes its slower. Keeping in mind that the
sms has the overhead of the sms framework this is
not at all bad :)

I think that tweaking the min_free, min_alloc and
max_free parameters can influence performance a
lot. So maybe that is worth investigating. [ofcourse
setting the max_free very high will emulate the
behaviour of pools, since pools hold on to all
the memory that is allocated].

Back to the naming of the thing. I first wanted
to call it sms_pool, because I adopted things
pools have. But, this would not be wise if we
rename all sms code from apr_sms_xxx to
apr_pool_xxx. Then it would be named the pool_pool
all of a sudden and that seems confusing.

I can now see why one would like to keep the naming
the same (since it is used in so many places and
it is an ADT anyway). However, I have the feeling
that pools were originally named pools for the way
they work: they pool memory (as in sharing
resources). With that background I find replacing
the sms namespace with a pool namespace a bit 
misleading. Ofcourse if I am alone in this I won't
make a fuss about it anymore (especially not when
this means Roy is coming after me with a baseball
bat :).

Well, that's all for now, enjoy the code and get
back with comments :)  Oh, I forgot to say, the
code lacks comments at the moment, so if things
are unclear in the code, please ask :) [I'll add
comments later]

Sander

PS. I'm always interested to hear about performance
    improvements :)

PS2. FYI: I am already working on an sms based on the
     trivial sms, which tries to avoid locking as much
     as possible in a multithreaded environment. It is
     close to being finished, but I would like some
     feedback on the trivial sms first, to find out if
     someone sees any problems in the code.