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 07:16:42 GMT
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
> > 
> > > note absurdity of apr_dbm_freedatum in a pool-managed implementation
> > 
> > The returned data is not always located in a pool. Specifically, GDBM's
> > return data is malloc'd. SDBM's return data is from a shared block of
> > memory. [hmm. sdbm's behavior should be clarified in the docs]
> Of course not, but it should be.

No way. No no no. You could pull several hundred Kbytes of data from a GDBM
record. We cannot and should not copy that into a pool. Take a page from
Ryan's book and attach a cleanup to the pool to free() the block at pool
cleanup time.

Hell, we use the cleanup function (rather than pool allocation) all over the
place in the bucket code.

There is no reason to take the hit of a memory copy when a simple
registration is sufficient.

> > We need a way to proactively toss GDBM's malloc'd memory. I also have a
> > pending item to go in there and register a cleanup just in case the caller
> > forgets to call freedatum.
> > 
> > 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.

> > >        note obscurity of apr_dbm_geterror in relation to apr
> > 
> > This isn't an issue. We have a set of error codes and strings that need to
> > be returned to the caller. This is very similar to how we handle DSO errors.
> similar != same  and it is even more likely to cause confusion.
> all our apr_err anything functions all copy an error message to the _user's_
> own char* buffer.  apr_dbm_geterror should do the same.

Ah. Right... we can make the char* buffer change. But putting the error code
into the APR error space isn't possible. This goes back to the old problem
of how do you map multiple error domains into a single space? We put the
main system errors in there, but alternate unbounded spaces (DSO errors and
DBM errors) cannot also be shoved in there.

So... the solution that we took for DSO errors (and DBM errors) is to have
an alternate function for fetching the domain-specific error.

I will make the prototype similar, though. Good point!


Greg Stein, http://www.lyra.org/

View raw message