httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: apr_dbm funkiness...
Date Wed, 07 Nov 2001 15:08:03 GMT
On Wednesday 07 November 2001 02:01 am, Greg Stein wrote:
> On Tue, Nov 06, 2001 at 07:28:34PM -0800, Ryan Bloom wrote:
> > On Tuesday 06 November 2001 06:38 pm, Bill Stoddard wrote:
> >...
> >
> > > So, either we need to replicate the value in memory with suitable
> > > lifetime scope (where? in apr_dbm_fetch? would need to pass in a pool
> > > to do this). Or not issue apr_dbm_close until we are done using the
> > > value.
> > >
> > > Thoughts?
> >
> > It should be up to the caller to copy the data.  Basically, after the
> > apr_dbm_fetch and before the apr_dbm_close, we should do a memcpy.
> What Ryan said. (or delay your close; but also note that other calls into
> the DBM could invalidate your pointer; two calls to fetch() could be bad
> :-)

Wow, that almost never happens on the first try.  :-)

> The API needs further documentation, but basically, the fetch() will *loan*
> you a reference to the value. The various DBMs implement this stuff in
> different ways, so the most optimal mechanism is to return a borrowed
> reference to the datum.
> If you *do* want to copy the thing, then it could even be possible to
> optimize further. Some DBMs actually *do* give you a reference and we just
> clean them up with a pool cleanup. If a caller wants a copy, then we could
> (theoretically) just shift the cleanup to the caller's provided pool.

I would prefer it if we didn't do the copy ourselves.  There may be times that
we don't need to copy.  If the data in the DBM is a simple integer value, and
we are going to check it immediately in a non-threaded app, I can do that 
without the memcpy.


Ryan Bloom
Covalent Technologies

View raw message