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? 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. 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. Or, is there a drawback to this that I am not seeing? -- justin
