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
