> On Dec 26, 2019, at 3:45 PM, Doug <dougf....@comcast.net> wrote: > > Can you explain what the API is that you use to "set concurrency levels per > connection", please? Is it a parameter on open() or its own function call? > And how would the API break, exactly?
sqlite3_config(), specifically the SQLITE_CONFIG_SINGLETHREAD, SQLITE_CONFIG_MULTITHREAD, SQLITE_CONFIG_SERIALIZED options. This API would break because configuring those options at runtime would have no effect on behavior; the only thing that would change threading behavior would be the compile-time flags SQLITE_MUTEX_OMIT, etc. (This is actually global, not per-connection, but that doesn't invalidate what I said.) > The talk suggested removing the SQLite virtual table of functions > (specifically the call to free a mutex). The user calls the function > directly. How does that break an API? If SQLite's implementation directly called the mutex lock/unlock functions, instead of indirecting, then there would be no way to control whether or not mutexes were used. In other words, it would be impossible to change any of the above options at runtime. > The talk suggested removing the SQLite virtual table of functions > (specifically the call to free a mutex). The user calls the function > directly. How does that break an API? No, the user does not call those functions directly. The code shown in the video is deep inside SQLite itself and not visible through the API. (You say you're using a TCL wrapper … so you may not be aware of what is or isn't in the C API. Trust me, I use the C API a lot.) —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
