On Apr 22, 2008, at 6:52 PM, Igor Tandetnik itandetnik-at-mvps.org | sqlite| wrote:
> Have thread B let thead A know that it wants in by using some > synchronization primitive. E.g on Windows I'd use a manual reset > event. > Thread A waits on the event at the top of the loop. The event is set > (signalled) most of the time, so the wait doesn't block. But when > thread > B wants to write, it resets the event, then tries to start the > transaction. On the next iteration, thread A would block on the event, > and thread B would go through. When it's done, it will set the event > back, which will wake up thread A. > > Igor Tandetnik > Thanks Igor. I gave a simplified example; I actually have 6 threads and they're in C++ but the code that they're actually running that uses the db is in Lua, so the C++ doesn't know at compile time which threads are likely to be annoying and do transactions in a loop. However, I could expose event functions to Lua from C++. I was hoping that I was missing something and that SQLite would manage this internally, but presuming I'm not missing some magic SQLITE_DONTOMIT_xxx definition in the amalgamation, the event seems like a good way to go. Thank you for the suggestion. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
