> 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 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. Otherwise we are warping a rather limited entity to handle this issue. 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. But we should recast the returned datum as const, at the least, since some dbm datum allocations are not in read-write memory. Bill
