Since multi-threading issues are notoriously troublesome, usually deciding to wait to appear until the software is deployed and under heavy load...
Is there a way to have multiple (perhaps only "select"?) queries running at the same time from a single thread? This would allow the OS to schedule the single-threaded application's multiple eventual reads more efficiently (elevator scheduling and all that) and allow the fast cpu to keep working while waiting for the much slower disk to return data. Reading about the busy handler I found out that sqlite is reentrant, and there is a progress handler that lets you do other work every N virtual machine opcodes, but I did not find anything that lets us do work specifically during the time spans when sqlite is waiting on the disk drive (unless that is what happens between v machine opcodes?) Is this currently possible with sqlite, or are the only option available to user multiple processes or threads to efficiently interleave multiple queries and while possibly also doing other cpu-bound work while the disk is busy? Perhaps there is some way using sqlite3_progress_handler with sqlite3_enable_shared_cache set, using one connection per simultaneous query, all in the same thread? --Tim Larson