Hash: SHA1

On 07/12/2010 02:59 PM, Nicolas Williams wrote:
> You can return an error to the caller too.  

That would require substantial surgery to SQLite.  Almost every routine
acquires and releases locks so they would have to be changed along with
SQLite mutex functions to deal with this (void to some sort of error code
plus returning that code).  Plus the changes would all need to be tested.

> But if this were integrated into libsqlite3 then the entry
> points could return an error.

Earlier you were trying to optimise out calls to getpid() and now you want
every SQLite function source to be changed?

> That said, it's better to abort() 

Indeed.  Another unmentioned constraint is that you don't want to compile
two versions of SQLite - one with the checks and one without.  That is why
swizzling the mutexes which are already runtime changeable is an attractive
solution, and doing an abort doesn't require code changes.

> 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
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.

Version: GnuPG v1.4.10 (GNU/Linux)

sqlite-users mailing list

Reply via email to