<RANT> I'm so mad I could spit. I haven't seen an interface as boneheaded as posix advisory locks in a long time. A very long time. Good grief. Windows has better interfaces than this. What an abominable design. What where they thinking???? </RANT>
Anyway, thanks to everyone for your suggestions. My first attempt at working around this posix design bug (that's what it is!) will be to modify sqliteOsClose() so that it checks for outstanding locks on the file that the file descriptor points to and defers the call to close() until all the locks clear. This will all happen inside a mutex, yadda, yadda, so that everything will be threadsafe, etc. The code is written. I just need to test it. But I'm too agitated at the moment. Need to go for a long run....
The only downside I see (and it is minor) is that the system will be holding the file descriptors in limbo until all the locks clear. That normally will not be a problem. How often do you have multiple locks on the same database within the same process? It can't be that frequent or we would have seen more database corruption over the past two years.
I'll also need to add bold-faced warnings in the documentation for users not to attempt to open the database file by any means other than sqlite_open() (in other words do call open() on the database file) or else risk corruption.
Thanks, everybody, for patiently listening to my complaints... -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
