While SQLITE_EXTRA_INIT is undocumented, it is used sparingly in SQLite itself, and by others.

The mutex guarding initilization is released before SQLITE_EXTRA_INIT is run which leads to a race condition in a multi-threaded environment because sqlite3_initialize happens automagically on many SQLite API calls, so the library can consider itself initialized before SQLITE_EXTRA_INIT has run.

Please move SQLITE_EXTRA_INIT under the protection of the init mutex.

Forgot to answer this yesterday. We now have SQLITE_EXTRA_INIT_MUTEXED, which is like SQLITE_EXTRA_INIT but without the race conditions you pointed out:

https://sqlite.org/src/info/67809715977a5bad

Dan.

I believe the WASM stuff should be using the mutexed version otherwise it is subject to the race condition.

Web-based WASM is, in its current form, single-threaded. In JS every thread is its own, almost-entirely-isolated JS engine, and each one which loads a WASM module gets its own, 100% isolated copy which shared no state (static or otherwise) from the underlying C code. Thus, even if the module is loaded and initialized 7 times concurrently, none of those can step on each others' toes. (Edit: the WASM build is also built with SQLITE_THREADSAFE=0, so mutexes are all noops there.)

There are not-quite-yet-ubiquitous ways to enable cross-thread sharing but we don't use them. AFAIK they're not standardized yet, and they definitely aren't widely-available enough for us to support them (e.g. very limited Android support).

I agree that it isn't a problem yet, but WASM is constantly getting closer to multi-threading no different than regular CPUs. Diagnosing this underlying issue is painful because sqlite3_initialize is implicitly called from many code paths, and developers love to use thread pools, so it will happen one day.

but WASM is constantly getting closer to multi-threading ... so it will happen one day.

Fair point. That change is now in the trunk. Thank you for the suggestion.