On Wed, Nov 5, 2014 at 7:10 PM, nicolas riesch <nicolas.rie...@gmail.com> wrote: > Pardon me, I will try to reformulate my question more clearly. > > My scenario: > > - sqlite is set to Multi-thread mode (SQLITE_THREADSAFE=2), or Serialized > mode (SQLITE_THREADSAFE=1) > - I create N logical threads in my "Go" program. > - Each logical thread creates a database connection, for its "exclusive" > usage. > Logical thread LT1 creates connection C1, logical thread LT2 creates > connection C2, etc. > Logical thread LT1 only makes call to connection C1, never to > connection C2, C3, etc. Same for other threads. > > Normally, in any mainstream language (C, PHP, etc), the same OS thread > makes the successive calls to sqlite3_prepare(), sqlite3_step(), > sqlite3_column(), sqlite3_finalize(), etc. > In the loop to retrieve all records in a table, there is no reason to call > sqlite3_step() on a different OS thread each time. > > But in Go, it is possible that each call to sqlite3_step() is scheduled to > run on a different OS thread. > Indeed, the execution of a logical Go thread (called a Goroutine) can > switch from one OS thread to another one, without the user being aware of > it, at each function call.
I'm the author of https://github.com/mxk/go-sqlite. You can't use a single connection and its derived objects from multiple goroutines without external synchronization, but as far as I know, there are no problems with the same goroutine being scheduled to different OS threads. I'm pretty sure that this applies to all other Go SQLite drivers as well. You actually can lock the current goroutine to a specific OS thread by calling runtime.LockOSThread(). Some things, like OpenGL, need this for thread-local storage and the other reasons that you mentioned. I don't think SQLite falls into this category. - Max _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
