apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: cvs commit: apr-util/src/dbm apr_dbm.c
Date Sat, 09 Dec 2000 07:25:26 GMT
> From: Greg Stein [mailto:gstein@lyra.org]
> 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:gstein@lyra.org]
> > > 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.


View raw message