I have a multithreaded application using SQLite 2.8.14. I fully understand, and have implemented, the requirement that each thread make its own call to sqlite_open() to obtain a unique handle to the database. I am using a thread synchronization scheme external to SQLite that has been fully tested and has been working well. I am not testing for the SQLITE_BUSY return on any call to the library since it should never happen. I did compile with THREADSAFE=1.
My issue is this:
At one point, using my memory leak detection utility, I believe that I saw a collision during the application shutdown when the worker threads were all executing the sqlite_close() call. The collision resulted in memory leaks from the SQLite library. I did not detect any corruption of the database file itself.
I wrapped both the sqlite_open() and sqlite_close() calls in the worker thread inside the mutex so only one thread at a time can make either of these calls. I have seen no problems since I did this.
Since then, for other reasons it has become inconvenient to have these calls inside the mutex, and I'm experimenting again with having them execute without thread synchronization.
Can anyone close to the SQLite code verify one way or the other whether this collision was a figment of my imagination or if I should really enforce thread synchronization during these calls?
Many thanks in advance for any insight. John
