On Mon, Jul 12, 2010 at 08:43:32PM -0700, Roger Binns wrote:
> > They're insane (the _first_, not last, fildes close(2) in a process
> > drops all locks on the underlying file), but the child won't clobber the
> > parent's locks.
> That is assuming all components (C libraries, threading, compatibility
> layers, operating system etc) are perfect.  Given how rarely these locks are

The point of support contracts is that you can assume crazy bugs like
you're supposing will be fixed (and, in this case, because of
conformance testing, won't happen in the first place).  If we not only
don't assume "perfect" components but also go so far the other way as to
assume these components are uselessly broken then we might as well go
home.  Surely the SQLite community sells support based on this very same

> used, and how many different platforms SQLite runs on as well as different
> vintages of those platforms, that is indeed a big gamble.  ie I would want
> to see evidence that they are all substantially right, ideally a way to
> establish (non-destructively) at runtime if some aren't etc.

The semantics of POSIX file byte range locking are well-defined.  The
operating systems supporting this feature have had it for very long
periods of time.  There are conformance test suites.  There's a lot of
things you might be able to suspect are broken, but when it comes to
POSIX file byte range locking (at least for Solaris anyways, which is
what I know best, implementation-wise) you can assume that the only
broken thing about them is their semantics, not their implementations.

Of course, well-tested-implementation-but-broken-design might not be
very comforting :(

sqlite-users mailing list

Reply via email to