-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/12/2010 08:53 PM, Nicolas Williams wrote: > On Mon, Jul 12, 2010 at 08:43:32PM -0700, Roger Binns wrote: >> Earlier you were trying to optimise out calls to getpid() and now you want >> every SQLite function source to be changed? > > No, just entry points into the library. What makes you think that I > meant that every function in the library should check this?
I also meant entry points but wasn't specific. There are a lot of them that acquire/release mutexes and every single one would need to be modified. That was my original approach until I hit on the idea of swizzling the mutexes instead. > 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. Having spent a lot of my commercial programming life with many different Unix implementations, including Solaris, I do not trust them, especially for little used functionality. And Solaris had many bugs in the past, but I haven't touched it in the last few years to form a recent opinion. (Like this one time when I found Sun's NFS implementation was broken based on log messages on an HPUX machine and then doing packet capture, and Sun invented NFS ...) In any event this roughly comes down to me saying to assume they are untrustworthy until it can be substantially be proven otherwise, and you seeming to believe that they are all correct seemingly based on extrapolating from a recent version of Solaris. Or being a pessimist and optimist respectively :-) This doesn't really matter. It is easy for anyone to add this functionality to SQLite by swizzling mutex pointers, does not require any changes or recompilation of SQLite, and can have whatever error behaviour desired, plus whatever micro-optimisations will make them happy. A straight forward implementation with an application that spends all its time in SQLite and with synchronous turned off (ie no disk waiting) will have a 1% performance penalty. Consider that a worst case. If enough people find this useful then there is a case for modifying SQLite itself. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw8Br4ACgkQmOOfHg372QR9dQCeM0D2j/KxC85yvVagFpdvxVro V3QAn3eu1HQTf0/ItPiDNe/AJmytVIy1 =Cbzq -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
