On Sat, Dec 09, 2000 at 01:25:26AM -0600, William A. Rowe, Jr. wrote: > > From: Greg Stein [mailto:[EMAIL PROTECTED] > > Sent: Saturday, December 09, 2000 1:17 AM > > > > On Sat, Dec 09, 2000 at 12:40:46AM -0600, William A. Rowe, Jr. wrote: > > > > > > > From: Greg Stein [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, December 08, 2000 5:47 PM > > > > > > > > And no... don't suggest we copy the return data into a pool allocation. > > > > :-) > > > > > > I'm suggesting exactly that. That, or the entire concept of a 'pool dbm' > > > is bogus, > > > as rbb keeps trying to assert. I don't agree, but if we are only taking > > > this half > > > way, then we are going in the wrong direction. > > > > No... we can use the pool for the cleanup, at a minimum. We also place some > > other kinds of allocations in there (files, the opaque structures, etc). The > > pool is more than just allocation... it is also a lifetime specifier. > > > > We aren't "going in the wrong direction" by not using its allocation. We > > allow GDBM to do its work, and return it. We don't stop and copy it all > > into > > a pool. > > Then we need a more flexible beast than our current 'pool' entity.
This doesn't follow. > This was suggested some time ago and nixed on new-httpd. I think it's time to > bring back up the concept of different 'pool' mechanisms. E.g., a shmem pool, > a malloc pool, an apache-style pool. Ryan whiteboarded it for me in SF a week > ago, and it makes a heck of alot of sense. What the heck? I don't see how those apply to this situation at all. A third party library (e.g. GDBM) allocates and returns some memory. We want to pass that to the caller without additional overhead (read: copying the bugger). For safety, we want to free it no matter what. The standard pool cleanup mechanism provides this. That is unrelated to where pool *allocations* come from (shmem, pools, mallocs). We aren't allocating any code, so it doesn't matter. > Otherwise we are warping a rather limited entity to handle this issue. Eh? We attach cleanups to pools all over the place. Again: consider how the buckets deal with freeing their malloc'd blocks. They attach a cleanup. We're doing the same here. > At a -bare-minimum- we need to create a store list to free on cleanup, of all > the allocated datum records retrieved. If the users -wants- to call > apr_dbm_freedatum, then fine, release it from the datum store list. Now you're complicating things. All we need to do is register a cleanup for each returned item. We don't need to maintain a free list; we just use the cleanup list in the pool. > But we > should recast the returned datum as const, at the least, since some dbm > datum allocations are not in read-write memory. This is essentially true, but the problem is that the datums are used for both input and output. Making the mem ptr in the datum "const" really impinges on the use of them for the input case. I tried it once :-) If you want to do this, then go and dig into it to figure out how. I've used the non-const variety for nearly two years without a problem, so I'm not seeing a big problem such that I want to spend time to fix :-) [ and note that two separate datum structures (one const, one not) isn't a very good approach since they need to be pretty interchangable; I tried that approach, too :-) ] Cheers, -g -- Greg Stein, http://www.lyra.org/
