apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr-util/src/dbm apr_dbm.c
Date Sat, 09 Dec 2000 08:01:34 GMT
On Sat, Dec 09, 2000 at 01:25:26AM -0600, William A. Rowe, Jr. wrote:
> > 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 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/

Mime
View raw message