For anyone who is interested i have created a standalone test case which demonstrates the threading behaviour that i had, or as close as i can get it. Feel free to use the code for whatever purposes you see fit.
It will compile on linux and windows, and comes with 4 versions of the sqlite libraries which can be found under "test/lib/sqlite/lib". Each platform has two versions, one built with THREADSAFE=0, and the other with THREADSAFE=1. http://ul1.rapidshare.com/files/10511098/test.zip It seems that i was incorrect in thinking the cause was sqlite3_step(). In replicating the problem from scratch i found that it was actually caused by sqlite3_finalize() being called without synchronisation. What does this mean, well firstly it means that the entire problem was avoidable had i simply synchronised correctly. But i think more worryingly, it highlights the fact that there is a great deal of confusion as to what it means for something to be thread safe on this mailing list. This confusion is also not aided in any way by the obtuse and stubborn attitudes that some people have demonstrated. If a lot of people are having regular problems with sqlite and threading as has been indicated then perhaps its time to review the situation. It is incredibly frustrating that the documentation and the various answers that i have recieved on this topic have been contradictory. At no time has anyone actually stood up and said that the software can safely be used in a multithreaded environment as long as access to the api's is synchronised. Instead you have a situation where the software has inbuilt misuse detection which may or may not alert the programmer to a potential error and a THREADSAFE macro which makes 5% of the it threadsafe but leaves the other 95% exposed. (By way of example using the code i supplied and the safe versions of the libraries it is possible to get away with calling sqlite3_finalize() outside the mutex, but if you take it one step further and use sqlite3_step() outside the mutex it will fail) So an inconsistent and unpredictable internal approach to thread safety combined with a policy of righteousness on this mailing list means that people like me have little chance of ever getting it right. Why is it so hard to simply nail down the characteristics of the software and update the documentation so that everyone is on the same page ? If sqlite is thread safe, and by that i mean it can be used safely with synchronisation, then why not say so. And be consistent in saying so. That way when someone comes here with a problem you can confidently describe how the api can be used and the user can go away and attempt to resolve their problem with confidence. I guess in part i owe people an appology, but then, had i been given a rational explanation or had access to clear documentation i guess this would not have gone on so long. And to be quite honest, my confidence in the software has now been eroded to such an extent that i dont know what is up or down. Please considder what im saying rationally and dont take offence. I know a lot of you are frustrated at this debate, and so you should be. I am too. So why not take steps to ensure that it doesnt happen again. Be clear about the threading behaviour and remove the inconsistencies. Fix the out of date documentation, and give a consistent answer, sqlite can be used with multiple threads provided that access to the api is synchronised. The saftey checks and macro options do more harm than good becuase they create confusion. Yes if you do X,Y, and Z you might get lucky, but thats probably why so many people have trouble. Its not consistent and its complicated. Unless your going to document the exact sequence of calls which is safe to make without synchronisation, you shouldnt be encouraging it. Advising people to create complicated designs where each thread has its own connection doesnt help either, because it will not work with transactions. It should be either 100% safe, or not at all. Perhaps it would also be useful to document the various strategies and ways in which sqlite can be used with safety. Stop telling people that mutlithreading results in random unpredictable behavior. Be open minded and don't hide behind whatever doctrine has been followed up till now. Emerson ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
