On Thu, Jan 2, 2014 at 4:28 PM, Florian Weimer <f...@deneb.enyo.de> wrote: > * Richard Hipp: >> The silly requirement of some distributions that *everything* must be a >> shared library irks me beyond words. I hate having to support >> --disable-internal-sqlite, and I hate having to add silly work-arounds in >> the code to accommodate distributions trying to use an older SQLite with a >> newer Fossil. This impedes progress and introduces bugs. It's a lose-lose >> situation. And yet the distributions are dogmatic on this point. > > Uhm, does POSIX file locking work correctly if there are multiple > copies of SQLite within the same process (assuming that there are no > symbol collisions/interpositions)?
No it doesn't. If you're using multiple copies of libsqlite3 to access the same DB file in the same process concurrently then you'll get corruption. In practice this just doesn't happen, but it's important to be on the lookout for this. Consider how that might happen by accident (as opposed to just for demonstration purposes). I imagine a plugin API for some library (think PAM) with multiple plugins... wanting to access the same DB -- or maybe the DB is the interface. That wouldn't happen, one hopes, and by and large it doesn't. Now imagine [wu]tmpx being replaced with a SQLite3 DB file... If [wu]tmpx were accessed using an in-process libsqlite3 and the library providing the [wu]tmpx functionality were itself available for static linking (or if the DB *were* the interface) *then* we'd have a situation ripe for this accident. But one could foresee this problem (hopefully) and act to head it off [various designs elided]. More generally, trying to ensure that a) there's only one copy of every library in the distro/OS, b) all version dependencies match up, is *super* hard, if not impossible. Eventually there are some very commonly used libraries where the simplest thing to do is to just ship multiple versions, but first the distro maintainer ought to make sure that the POSIX file locking disaster you mention can't happen as a result. It's fortunate, for example, that OpenSSL doesn't use POSIX file locking at all. Imagine it using SQLite3 for an OCSP response, CRL, and other caching! It's not such a stretch. Heimdal has an option to use SQLite3 for Kerberos ticket caching, and when used this happens in a library, which is itself used from a pluggable API (GSS) that is used in various operating system moving parts (e.g., LDAP). The problem with POSIX file locking and something like SQLite3 is that it's easy for all the pieces of such an accident to come to exist... by accident. The problem is that POSIX file locking is insane. Nico -- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
