On Wed, Oct 26, 2022 at 1:59 PM Emmanuel Dreyfus <m...@netbsd.org> wrote:
> On Tue, Oct 18, 2022 at 05:03:48PM +0000, Emmanuel Dreyfus wrote: > > dbm is fast once you have it open. mod_dav_fs opens DAVLockDB on each > > HTTP request, then it acquire a filesystem level lock on it. This is > > where contenton occurs. > Gotcha. Yes, that makes total sense. > I have been thinking about how Apache could open DAVLockDB once, instead > of for each HTTP request. The workers should share a file descriptor > on the file, and a mutex to avoid concurent access. > > That does not fit well with the prefork model. Opending DAVLockDB > and creating the mutex (a sysV mutex?) should be done in the master > process. Should it be done when processing the configuration directive? > > We would also need to take care of closing the previous file descriptor on > reloads. > That's gonna get very tricky across the various MPMs. dbm wasn't really designed for this. When I wrote mod_dav way back when, SQLite was not available. That is where I'd go today for the lock database (and properties). It handles multi-process, multi-thread, and is very efficient. If you are sufficiently motivated, that would be an excellent path forward. With that said, I'm not a fan of [DAV or svn] locks. Anything that can be done to avoid a workflow that encompasses locks would be ideal. Cheers, -g
