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: SDBM locking...
Date Sun, 13 May 2001 17:44:30 GMT
From: "Justin Erenkrantz" <jerenkrantz@ebuilt.com>
Sent: Sunday, May 13, 2001 11:58 AM

> On Sun, May 13, 2001 at 04:20:11AM -0700, Greg Stein wrote:
> > I didn't see a problem in my code review. Justin: are you actually seeing
> > calls to fcntl/flock/whatever in an strace output? (note that you can't
> > really use calls to apr_sdbm_(un)lock since they could be fast-pathed in
> > most cases)
> Wow.  I saw this last night, but now on a fresh build (with fresh eyes),
> truss shows it doing the correct behavior.  My bad.  Sorry.  Looks good
> and it is doing the right thing.  Maybe I had some stale objects 
> somewhere.  -- justin

Possibly you grabbed the tree in one of the transitive states.

There was an extra wasted stat() call, which is now gone, so it should even
be nominally faster yet :-)

If you can break your code into reasonable locking units, feel free to actually
use the APR_SHARELOCK bit in your apr_sdbm_open call, and lock/hold while you
are bouncing about.

I did notice the discrepancy when trying to call apr_sdbm_firstkey [unlock/flush]
followed by apr_sdbm_nextkey ... so it's documented in the header file by 
cautioning the programmer to open their lock, and then call firstkey/nextkey[...].

Hadn't considered the issue of an intervening fetch, and that does look like it
could be broken (dunno if it is.)  Suggests we want a setaside for the 'current'
key, so you might want to look at that (feel free to offer a patch.)  At least to 
document what else breaks the firstkey/nextkey operation, besides the locking.


View raw message