apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <ad...@rowe-clan.net>
Subject Re: SDBM locking...
Date Sun, 13 May 2001 06:04:56 GMT
From: "Justin Erenkrantz" <jerenkrantz@ebuilt.com>
Sent: Saturday, May 12, 2001 9:48 PM

> This message is really directed towards Bill and Greg...
> What is the status of the SDBM locking code?  I know that Bill
> committed some stuff to implement reference counting and other 
> things.  I'm not sure if he finished that commit or not (I think so).
> In my "tests" (if you could call them that), the mod_mbox code is 
> spending a lot of time obtaining and releasing file locks related to the
> SDBM code (besides writing to the network).  Is there any plan to 
> implement either a fast path without locking or to somehow address the 
> locking speed?

Ummm... my locking patch should do effectively nothing if you don't ask
for locking --- that points to a bug in my patch.

> Wouldn't it be possible to just hold the file lock for the duration that
> we have the SDBM open rather than obtaining and releasing it at every
> call?  So, if you open with an exclusive lock, you get an exclusive file
> lock on the DBM until you close it.  The file handle is open at all points,
> so I'm not sure what the logic is for getting and releasing the file
> lock at each call - the cache is almost useless because it'll be
> invalidated all the time.  

Should be exclusive only if you open it R/W (and not Shared) _or_ if you
open it shared, and either lock on your own _or_ perform a store/delete.

> If a shared lock on that file exists, exclusive locks will block until
> the shared locks are released (shared locks should not be affected), and
> if an exclusive lock is held by someone, everyone waits until it is
> released.

Correct, that's why I'm not certain what exactly you are seeing.  I'll
review the code yet again tommorow.

View raw message