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: svn commit: r512557 - in /apr/apr-util/trunk: CHANGES dbm/sdbm/sdbm.c
Date Wed, 28 Feb 2007 20:27:30 GMT
Another alternative, we can either write lock the file by all readers,
or perhaps easier but probably more cpu intensive, lstat to pick up the
modification stamp?

I'm still apprehensive about the assumptions here, if our buffering was
block oriented this wouldn't be an issue, but the SDBM is block oriented
and our buffering is stream oriented.

William A. Rowe, Jr. wrote:
> Joe Orton wrote:
>> On Wed, Feb 28, 2007 at 08:29:10AM -0800, Justin Erenkrantz wrote:
>>> The performance implications of not doing buffered reads just *kills*
>>> our server - so we need to do something and adding buffering lessens
>>> the load quite dramatically.  In our situation, we couldn't care less
>>> about modifying the file - we only care to optimize the read-only case
>>> - and I believe that code is just fine and stable.  Though I guess I'd
>>> prefer we fix the problems with buffering if they do exist.
>>>
>>> Would you be concerned if we added APR_BUFFERED to APR_DBM_DBMODE_RO
>>> for sdbm?  -- justin
>> No, that sounds fine, or just moving your change up inside the !(flags & 
>> APR_WRITE) condition so that all apr_sdbm_* users benefit equally.
> 
> -1 on this change unless you compare the datum you do hit that it's still
> the record you expected.  If we hit the wrong record (our copy of the
> buffered index page mismatched the found page) we must flush and retry
> once.  If the retry fails, then error out.
> 
> Bill
> 
> 


Mime
View raw message