On Mon, Jul 12, 2010 at 11:25:07PM -0700, Roger Binns wrote: > > 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.
There's about ~170 entry points, depending on which version of SQLite3. There's about ~110 calls to sqlite3_mutex_enter(), and about as many to drop mutexes. Some mutex enter/leave calls might occur in loops (haven't checked), but already ~170 < ~220 :) Not that such a static analysis says much. Most apps probably use a small sub-set of entry points, and estimating the number of mutex calls on average per-call to one of those entry points is non-trivial. But the point is that I would generally expect #-of-entry-points < #-of-mutex-calls -- that needn't always be true, but it's probably a good rule of thumb. Your approach does allow you to implement fork-safety without modifying SQLite3 source itself, which is pretty cool. But that's not necessarily how the SQLite3 maintainers might do it. > > 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. [...] I can't argue with detail-free anecdotes. And I'm sure there have been bugs. I do have access to the Solaris bug database, so I could search it, but by then I'd be spending an enormous amount of time just to argue a rather minor point. If you fill in some details I will do a search for the bugs in question though (since details will help narrow down the search). Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
