CGI installation and SQLite thread safety
(1) By H.B. (HandyBook) on 2023-11-21 00:24:44 [link] [source]
While compiling Fossil for use as a CGI script, I noticed that SQLITE_THREADSAFE=0 was defined.
I was unable to find a configure option to change the definition, so I resorted to modify and run tools/makemake.tcl to update src/main.mk
However I wonder if the configure option was missing simply because fossil makes the synchronization primitives used by SQLite somehow redundant, for example by acquiring an exclusive lock on the database at each execution (maybe just when running as CGI) or something like that.
Is SQLite thread safety actually needed for CGI execution? If so, is there a better way to get it?
PS: thanks for this wonderful tool! :)
(2) By Larry Brasfield (larrybr) on 2023-11-21 00:33:48 in reply to 1 [link] [source]
Is SQLite thread safety actually needed for CGI execution?
No. When using Fossil as a responder via CGI, it runs single-threaded.
(3) By H.B. (HandyBook) on 2023-11-21 00:51:43 in reply to 2 [source]
Fine.
But what if two concurrent HTTP requests commit changes to the SQLite database?
In this scenario I suppose two different fossil processes that, despite each single threaded, need to synchronize their access to the database file.
Am I missing something obvious?
(4) By Warren Young (wyoung) on 2023-11-21 01:02:48 in reply to 3 [link] [source]
CGI launches a separate executable instance for each HTTP hit. There’s your multiple threads right there: one per process.
(5) By H.B. (HandyBook) on 2023-11-21 01:18:57 in reply to 4 [link] [source]
Indeed: thus I'd say that running fossil in a CGI environment actually needs thread safety.
My question is if this means that we need to compile it with SQLITE_THREADSAFE=1 and if so if there is a better way than what I did.
Actually, I'm not even sure that in such scenario enablying SQLite thread safety would be enough with the default VFS: maybe I should set the FOSSIL_VFS environment variable? Maybe to unix-excl?
(sorry for the stream of questions... it's the first time I have to configure fossil for CGI execution)
(6) By Larry Brasfield (larrybr) on 2023-11-21 01:21:38 in reply to 3 [link] [source]
Am I missing something obvious?
I'm not sure about obvious, but something to consider:
There are two main categories of concurrent access that the SQLite library must contend with: (1) concurrent access to the DB file(s); and (2) concurrent access to the in-memory data structures maintained by the library code.
Category 1 is safe-guarded by the library design, regardless of provisions for safe-guarding category 2. Only category 2 access is affected by the value of SQLITE_THREADSAFE during the library build. When only one thread will be using the library data structures within a process, SQLITE_THREADSAFE=0 is fine.
(7) By H.B. (HandyBook) on 2023-11-21 14:35:15 in reply to 6 [link] [source]
concurrent access to the DB file(s) [...] is safe-guarded by the library design, regardless of provisions for safe-guarding category 2.
Thanks a lot Larry, it's much more clear now... :)