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