From: "Justin Erenkrantz" <[EMAIL PROTECTED]> 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. Bill
