To clarify a couple of things in response to queries: my time for
divestment is "not yet"--but rest assured, when it arrives, I will
certainly see who wants things from my assortment (don't get too excited;
there's nothing super-rare or valuable in it, and I've always been more
concerned with restoring functionality than maintaining period-correctness;
I am one of those collectors who restores stuff to play with it, not to
then put it in shrinkwrap and preserve it for some uncertain future). And
should that time arrive suddenly, well, argh, I've been putting off making
a will too long, but I know who I'm going to put in charge of "everything
computery," and I trust her to make good decisions about the things she
doesn't want.
My understanding of sqlite (and it could be wrong) is that concurrent
writes aren't supported, and reads should block if a write is in progress
until the write completes. In practice it seems like most things are
one-sqlite-file-per-process and if that process is threaded, one would hope
the programmer understands what they're doing well enough to make it work.
There are fairly few cases I've seen where a single sqlite file is shared
between unrelated processes, which would take filesystem locking working
correctly to ensure correctness. Which is generally OK for local
filesystems, but NFS is still a bucket of worms when it comes to locking
behavior, and the number of people running systems that genuinely
understand NFS has been declining for decades. (I do not count myself
among those people.)