One of our Linux programs (not written by me) is reporting errors of
the form "SQLITE_CORRUPT: database disk image is malformed database
corruption". Due to timing constraints, it performs all read queries
in one thread and creates a temporary POSIX thread for each update
query (this is the developer's reasoning). Due to memory constraints
(at least 1MB is consumed per connection!), only one database
connection is used. Any thread may acquire and use this one database
connection at any time.
The connection open mode is RW,FULLMUTEX (equivalent to
SQLITE_CONFIG_SERIALIZED).
A few queries may use sqlite3_exec() but most queries done by this
program use sqlite3_prepare_v2()/sqlite3_step()/sqlite3_column_foo()
and prepared statements.
The documentation at https://www.sqlite.org/threadsafe.html seems
unclear in that it claims thread safety without documenting under
which use cases it is thread safe.
If we have two threads executing sqlite3_step() on the same connection
and using their own prepared statement, is there any magic in sqlite3
which would keep sqlite3_step() and sqlite3_column_foo() from
consuming (or disrupting) the results from the other thread?
In this use case is sqlite3 usage "thread safe" or is behavior
unstable due to sqlite3_step(), sqlite3_reset(), and result column
accessors accessing/disrupting data from the result set of the other
thread?
Thanks,
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
