For Litestream to work on BSD, there's no alternative but to use POSIX advisory locks on the Wal index.
Locking the entire file with flock, as we're currently doing, is “failsafe“ (no corruption can result from it), but it violates the SQLite locking protocol.
Fortunately, although POSIX locks are awful, we already only keep a single file descriptor to the Wal index file which fixes most issues with them. Instead of opening, and stating for SameFile we can stat and open (which introduces a race, but there's no way around that).
We're also already assuming we must open the Wal index read/write on BSD, which makes things easier.
And Implementing xShmLock with a mix of POSIX and memory locks is also much easier that xLock.
I still hate POSIX locks, but maybe it's not so bad for this, and it should improve things significantly.
This should make it so that Litestream works on BSD, which https://github.com/superseriousbusiness/gotosocial/issues/1753 really wants.
For Litestream to work on BSD, there's no alternative but to use POSIX advisory locks on the Wal index.
Locking the entire file with
flock, as we're currently doing, is “failsafe“ (no corruption can result from it), but it violates the SQLite locking protocol.Fortunately, although POSIX locks are awful, we already only keep a single file descriptor to the Wal index file which fixes most issues with them. Instead of
opening, andstating forSameFilewe canstatandopen(which introduces a race, but there's no way around that).We're also already assuming we must open the Wal index read/write on BSD, which makes things easier.
And Implementing
xShmLockwith a mix of POSIX and memory locks is also much easier thatxLock.I still hate POSIX locks, but maybe it's not so bad for this, and it should improve things significantly.
This should make it so that Litestream works on BSD, which https://github.com/superseriousbusiness/gotosocial/issues/1753 really wants.