On Wed, Nov 21, 2012 at 4:10 PM, Mikael <[email protected]> wrote:
> Dear Dr. Hipp, > > There's with great reason there's the SQLITE_THREADSAFE=1 mode and also > the possibility to run several statements in parallell on one CPU core. > > Ensuring that no DB activity happens between that you do sqlite3_step() *on > a stmt* and sqlite3_changes() and sqlite3_/extended_/errcode() *on (as > in, regarding) the same stmt* is like the most cumbersome requirement ever, > requiring complexity and CPU resources spent by the user. > SQLite serializes access to each database connection. So if you have two or more threads trying to run different prepared statements from the same database connection at the same time, mutexes will ensure that only one thread runs while other the others wait. There is no parallelism at the prepared statement level. You can have two or more threads running prepared statements from different database connections at the same time and they will run in parallel, mostly (subject to operating system restrictions.) So, yes, we could add a few extra interfaces to SQLite to make things easier when running multiple prepared statements from the same database connection in different threads. But those extra interfaces are extra work to maintain and test and they do add overhead, however small it might be. And they are only useful to applications that are doing things that they maybe shouldn't be doing in the first place. If you really need to do this, you can make your own wrappers around sqlite3_step(). Use sqlite_db_mutex() to get the mutex for your database connection. Call sqlite3_mutex_enter() on that mutex. (It is a recursive mutex so doign that is safe.) Run your sqlite3_step() then sqlite3_changes() and/or sqlite3_extended_errcode(), and save the results of the last two in some fields of your wrapper object. Then run sqlite3_mutex_leave() on the DB mutex and return the result of the sqlite3_step(). If you write such a wrapper, then accessing the information you need becomes painless for you, and it does not add overhead to the millions of other SQLite applications that do not need it. > > The expense in SQLite of keeping track of changes and error code on a per > statement level can't be more than a 16 bytes per statement and a couple of > CPU instructions, can it? I mean, everywhere in SQLite's code where changes > or errcodes that regard a stmt are registered, the actual stmt regarded is > in some local variable already anyhow isn't it? > > SQLite is an overwhelmingly good library, though this particular thing is > really a matter of non-elegance from a user point of view, I mean there's > an enormous amount of cases where you want to check errcode or/and pick up > the number of changed rows right after sqlite3_step() so why design for > putting expensive-enough complexity on the user when there's no need for it? > > Thank you and with warm regards, > Mikael > > -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
