Quoth Dustin Sallings <dus...@spy.net>, on 2010-10-04 19:25:05 -0700: > I did read that, but I didn't quite understand what the global state > is that will be accessed between otherwise independent > threads. Reading the code makes that a bit more clear.
Consider things like how POSIX file locks are per (process, inode) tuple and get destroyed on any relevant fd close, and therefore SQLite has a considerable amount of shared-state logic to keep fds for the same inode open so long as any of them needs to be locked. (The fact that your particular fds won't have this property (if you're on a relevant platform) doesn't mean the shared state isn't necessary to check.) That's an example of why thread-awareness would be necessary even for accessing completely separate databases in separate threads. Multiple threads should not access a database handle concurrently regardless of any of this. ---> Drake Wilson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
