> On Dec 30, 2019, at 7:19 AM, Doug <dougf....@comcast.net> wrote: > > I am suggesting that if the we added the global calls to the underlying > functions to the API - that is, the functions that are called by the function > table indirection - then one could code the application to call the > underlying functions.
What you're describing is basically the SQLITE_CONFIG_SINGLETHREAD compile option. In that configuration SQLite does not use any mutexes, and you're responsible for "call[ing] the underlying functions" (the mutex lock/unlock functions) yourself. However, in this configuration any client code that makes concurrent calls to SQLite — and there is a lot of code like that — will crash and burn. > If you are going to tell me that you need to maintain two versions of your > application if you run it in a single-thread environment or a multi-thread > environment I don't know if someone else was saying that; what I was pointing out earlier is that many clients of SQLite link to it as a shared library provided by the OS, either built-in (as on iOS and macOS) or installed by a central package manager (Linux). This means they don't specify compile-time options, they implicitly get the behavior configured by the OS or package vendor, which I'd guess is probably MULTITHREAD. If the SQLite they link with changes its behavior to avoid mutexes, many of these programs will break. > Thinking about it, I'm surprised that the C API isn't just a set of macros > already. What you're describing is basically the effect of link-time optimization (LTO). The optimizer runs over the entire program's compiled code (not just one compilation unit) and applies optimizations such as inlining. This can indeed have a big impact. —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
