Skip to content

Conversation

@jeremywrowe
Copy link
Contributor

This change removes ffi::sqlite3_config() and ffi::sqlite3_initialize() from local/database.new and moves the configuration down to local/connection#connect. This is done because a SQLite connection can not be initialized multiple times, this change frees users of the library to intialize SQLite connections at a different level. initialize specifically presents a problem when libsql is being included in a shared library where there are other shared libraries that interact with the SQLite C API. This change should be relatively safe, since connections can change the threading mode on a per connection basis so long that sqlite was compiled with SQLITE_THREADSAFE=1 or SQLITE_THREADSAFE=2.

Refs:

This change removes ffi::sqlite3_config() and ffi::sqlite3_initialize()
from local/database.new and moves the configuration down to
local/connection#connect. This is done because a SQLite connection can
not be initialized multiple times, this change frees users of the
library to intialize SQLite connections at a different level. initialize
specifically presents a problem when libsql is being included in a
shared library where there are other shared libraries that interact with
the SQLite C API. This change *should* be relatively safe, since
connections can change the threading mode on a per connection basis so
long that sqlite was compiled with SQLITE_THREADSAFE=1 or
SQLITE_THREADSAFE=2.

Refs:

* https://sqlite.org/threadsafe.html
* https://sqlite.org/c3ref/c_config_covering_index_scan.html#sqliteconfigserialized.
@jeremywrowe jeremywrowe force-pushed the remove-sqlite-connection-init branch from 6a6415f to 32296ab Compare December 19, 2024 15:56
let flags: c_int = ffi::SQLITE_OPEN_FULLMUTEX | db.flags.bits();

let err = unsafe {
if ffi::sqlite3_threadsafe() == 0 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is actually safe, because accroding to the docs a user can still enable the threading model in such a way that it invalidates the assumptions the rust code has via sqlite_confgi

The return value of the sqlite3_threadsafe() function shows only the compile-time setting of thread safety, not any run-time changes to that setting made by sqlite3_config().

So this to me isn't strong enough to enforce 100% (esp with sqlite having global config) that the send/sync bounds we have in rust are safely implemented.

@LucioFranco
Copy link
Contributor

closing in favor of #1891

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants