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 idea. > 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 :( Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
