Nicholas, Thanks again for your patience, i think were getting somewhere.
As an aside, can i just say that i dont understand why concurrency is always such a point of confusion. I think it should be a basic assumption that when people talk about accessing api's and data structures in a multithreaded environment they talk about doing it in a synchronised way. Unless otherwise specified, concurrent modification of any data structure which involves state is always unsafe. Anyway, i have removed the misuse detection. My application now runs fine without crashing, and i can use the multiple thread, single connection, single transaction design so it is about 25% faster than the other alternatives i have tried. I simply commented out the code in the sqlite3SafetyOn() and sqlite3SafetyOff() methods and had them both return 0. Assuming i didnt just get lucky, this means that the safety functions were responsible for triggering the misuse i was seeing and that this is probably due to the safety functions themselves not being used in all the necessary places to correctly track the state even under synchronised concurrency. If it really is the case that there is no reason why sqlite should be thread unsafe when synchronised correctly, then why are those safety functions there ? If they are there to detect circumstances where the api is used and not synchronised then i would suggest that they are doing more harm than good. As i dont know the code well i cant be certain that what i have done is enough to make it completely error free. Perhaps someone who is familiar with the safety functions can comment more on this ? Emerson On 1/4/07, Nicolas Williams <[EMAIL PROTECTED]> wrote:
On Thu, Jan 04, 2007 at 12:50:01AM +0000, Emerson Clarke wrote: > My oppologies, your right that explanation had been given. OK. > But i didnt actually take it seriously, i guess i found it hard to > believe that it being the easier option was the only reason why this > limitation was in place. SQLite is a large pile of code. Other libraries that I'm familiar with that have taken this approach are larger still. Retrofitting MT-safety into these is hard, so the easiest path is often taken. (It may be that SQLite was always intended to be MT-safe, but I don't know that for a fact.) > If this is the case, then surely the fix is simple. Given that i > assume it is safe to have multiple sqlite3_step() calls active on a > single connection on a single thread. And given what you have said > about sqlite not already checking data structures that would be shared > by multiple threads, then surely all that needs to happen is for the > misuse detection to be removed. Your first assumption, as has been explained repeatedly, is incorrect. Oh, wait. I think I understand what's happening. You've missunderstood what you've been told (your next paragraph makes me think so). You *can* use sqlite3_step() with the same db context in multiple threads, you just have to synchronize so this doesn't happen *concurrently*. If you remove the misuse detection but don't synchronize I believe you'll find that your application will crash or worse. > Since there is usually nothing which needs to be done to specifically > make any api thread safe other than synchronising access too it. If > by synchronising access to the api calls i can ensure that no two > threads use any data structure at the same time, everything should > work fine right ? Yes. Nico --
----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
