> I'm still not 100% sure if there's a problem sharing connections across > threads with SQLITE_OPEN_NOMUTEX as long as I guarantee that they aren't > concurrent. I suspect there aren't, but I'm not 100% sure. Any case where > sqlite3 would be less than happy that pthread_self wasn't always the same?
As long as you guarantee that the same connection is not used concurrently in different threads SQLite will be happy with any mix of threads. But apparently your "not 100% sure" is actually "it's not true" in this case (as your tests showed). Pavel On Sun, May 15, 2011 at 4:51 PM, Steven Parkes <smpar...@smparkes.net> wrote: > Ah, crud. I kinda forgot I had a WAL checkpoint thread running. I thought I > had disabled that a long time ago. And it was sharing a connection on a > different thread. > > Fixing that, things seem stable under GCD with SQLITE_OPEN_NOMUTEX. > > I'm still not 100% sure if there's a problem sharing connections across > threads with SQLITE_OPEN_NOMUTEX as long as I guarantee that they aren't > concurrent. I suspect there aren't, but I'm not 100% sure. Any case where > sqlite3 would be less than happy that pthread_self wasn't always the same? > > Note that this isn't me redoing what sqlite3 is doing: GCD provides a higher > level abstraction that guarantees (modulo my stupidity) non-concurrency. It > should be enough for SQLITE_OPEN_NOMUTEX while being (at least slightly) more > concurrent than SQLITE_OPEN_FULLMUTEX. > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
