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
