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: cvs commit: apr/threadproc/unix thread.c
Date Thu, 07 Jun 2001 13:54:24 GMT
On Wed, Jun 06, 2001 at 04:34:22PM -0700, Justin Erenkrantz wrote:
> On Wed, Jun 06, 2001 at 11:47:53PM +0100, David Reid wrote:
> > This is the crux of the issue methinks.  We don't yet have a module that
> > would allow us to even get close to replacing pools.  We need a lot of
> > things from it and Sander and I have had some good early discussions about
> > how it could work.  Basically we want to have a fast, stable tracking
> > allocator that has a smaller memory footprint than pools.  Is it possible?
> > I don't honestly know but we're going to give it a good try.  Why haven't we
> > opened up our discussions?  Because we haven't even got any code and are
> > still bashing around the early design which is probably better done
> > privately.  Once we have something we like we'll post.
> 
> See, I think this is the difference.  I see that the pools are on top of
> sms.  (Gee, this is what Cliff said...)  The sms doesn't need to know
> anything about refcounting or anything special.  What does refcounting
> give you?  I'm still not also sure why locking needs to be in the SMS.

because, by handing over responsibility for locking of memory to
SMS, and by having the pools code use SMS, you make the pools code
a) simpler b) more powerful.

only an SMS instance should know exactly how to deal with its
memory - _including_ locking - IF it is needed.

as people have already pointed out.

if you want the same thing _without_ using SMS, but you still want
pools as an interface to shared memory, to mlock()/GlobalLock()ed
memory, to this memory, to that memory, to even _files_ implemented
as memory - _whatever_, then you must code into pools the capability
to do locking of shared memory, locking of this memory, locking
of that memory, and it's just such a messy nightmare that no-one
in their right mind wishes to consider it, and i _agree_ with them :)


> (I think I asked for clarification on this, but I received none...)
 
whoops :)  does the above help? :)


> All an sms knows how to do is to get a chunk and free a chunk of 
> memory.

uh... not quite.  and it knows how to manage it.  keep track of
it.  lock it [_if_ needed: that is up to the implementation].

_and_ the management can be done by using some _other_ sms
[parent sms] to use, which may be quicker, better, niftier,
sliced-breadier whatever.

> None of the pool logic needs to be in sms.  

??? what code are you looking at?  :)

you've examined the tracking memory system, yes?

and the destroy and reset?

> I saw that the sms 
> were just an abstraction around allocating memory.

correct.

> The pool will 
> actually handle the cleanups.  

well, we have to provide cleanups in sms _anyway_.

if, as the implementor of pools, you [whoever] choose not
to leverage the functionality [sms cleanups] to make
the pools code simpler, well, then... that is your choice.

> Everyone still uses apr_pool_t.

that is correct.  i would not imagine for one _second_ that
this would not be considered unless it could be done
as a #define in apr_compat.h, and even _then_ i would,
as david recommends, only slate it for some distant future
release.

>  The 
> pool itself uses apr_sms_t to allocate memory.  This enables us to have 
> a shared memory pool, a file-backed memory pool, a heap-backed memory 
> pool - whatever we want.  

correct.

> The sms doesn't need to do any locking - the 
> pool will guarantee that the allocation is done atomically by its own 
> locking mechanisms (what it does now - albeit the pool locking is a bit
> coarser than it really needs to be).
 
wrong.  how can pools know what type of locking is required
for each type of sms it _might_ use, without turning pools into
a nightmare of spaghetti #ifdefs and #ifthatdefs that the sms
API is designed *exactly* to avoid???

see above: i explain further.

> I think the thing is that I've seen the sms as slightly different than
> what it was originally posted as.  

i think that is the case, yes.  either that, or we haven't
explained it enough.

concepts tend to spring from sander and i like fully-formed hydras.
getting them across without bashing heads together is an interesting
learning experience - for me, at least :)

> So, I might be in the minority here.
> I think we are seeing two different views of what an sms should be.

i hope not.  i'll try to keep an eye / time on these discussions
to make sure everyone who _wants_ to know does know.

to that end, the idea was floated that perhaps those people who
wish to get together head-to-head to discuss /implement this
contact me?  i have two possible venues in the u.k. where it will
be possible to invite up to... 5 people at one venue, and ...
10, maybe? at the other [50 _would_ be pushing it, a bit:
all the rooms are empty but it'd be feasible if uncomfortable :)] -
some time in july, august or september?

[hm, time to get a cable-modem, i think :) ]

all best,

luke


Mime
View raw message