apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: cvs commit: apr/threadproc/unix thread.c
Date Wed, 06 Jun 2001 23:34:22 GMT
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.
(I think I asked for clarification on this, but I received none...)

All an sms knows how to do is to get a chunk and free a chunk of 
memory.  None of the pool logic needs to be in sms.  I saw that the sms 
were just an abstraction around allocating memory.  The pool will 
actually handle the cleanups.  Everyone still uses apr_pool_t.  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.  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).

I think the thing is that I've seen the sms as slightly different than
what it was originally posted as.  So, I might be in the minority here.
I think we are seeing two different views of what an sms should be.

My -1 was non-veto, so it doesn't stop you.  It just registers my
dissent.  -- justin

View raw message