Am 03.02.2011 15:53, schrieb Pavel Ivanov: > It seems that this explanation as well as all other statements in the > thread you linked are coming from the wrong assumption that SQLite's > handles cannot be used from any thread other than the one created that > handle.
The explanation I gave to Stefano is *not* based on the assumption that SQlite handles can't be passed from one thread to another. But certainly passing them around *can* lead to problems. > Although this was true in some earlier versions of SQLite it's > not true in the current version. So if SQLite is compiled with > THREADSAFE=1 (as mentioned in that thread) then you can do with it > whatever you want. Just beware of possible data races and potentially > uncommitted transactions because of some open statement handles. And > if as you say there's no simultaneous access to the database from > different threads then there's no difference in your usage pattern > from single-threaded one. I cite from http://sqlite.org/faq.html#q6: "The restriction on moving database connections across threads was relaxed somewhat in version 3.3.1. With that and subsequent versions, it is safe to move a connection handle across threads as long as the connection is not holding any fcntl() locks. You can safely assume that no locks are being held if no transaction is pending and all statements have been finalized." The problem is that Stefano wants to pass a result set from one thread to another. The result set has an associated SQLite statement handle which is inherently *not* finalized. And that might cause trouble. If access to the database handle is serialized as Stefano claims passing the statement handle between threads shouldn't cause problems, true, but in that case I don't see the advantages of having a separate thread over using a global database access instance. Regards, Ulrich _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
