"D. Richard Hipp" <d...@hwaci.com> schrieb im Newsbeitrag news:fb9c47d5-1b72-4574-bb44-4f0d6685f...@hwaci.com...
> FWIW, we are in the process of "productizing" the > test_async.c asynchronous VFS for SQLite. > The new async VFS might be available as a compile-time > option or as a loadable extension on both windows and > unix in 3.6.14. > The async VFS does all disk writes in a background thread... > ... > The async VFS also uses more memory, since the data > waiting to be written to disk has to be stored somewhere. Not that much of a problem nowadays (at least if not running on an embedded device)... > It might use a lot more memory if you are committing changes > to the database faster than the disk and the background writer > thread can handle them. That's understandable - and Ok - but leads to some questions: (assuming we are running on windows as in my case) How's the "read-uncommitted"-case handled then in the main-thread of the hosting process - is there an "automatic cross-thread-linking" to the "yet to write to the disk"-pages and the Selects already get (merge) their data from these pages? And how would we have to handle the case, if the user simply is closing the Application-process gracefully (for example by closing the Main-Window) - but your writerqueue yet contains outstanding writejobs? Is there some "state-info" which we could check - and set the process "on-hold" by ourselfs until all writes are finished? Is there only one vfs-WriterQueue-Thread per process - or is it per Connection (DB-Handle) - I assume per process, but just to make sure... In case there is just one WriterQueue-Thread per process - is there any chance, that the current backup-implementation could make use of that central writer-thread? I mean, in case of the more granular working backup-mode, which automatically retriggers itself in case of some writes on another DB-Handle (Connection) - we can currently not use this "low-prio"-backupmode on our AppServer, which holds "per-thread" DB-Connections in its WorkerThread-Pool. Currently, if we start an additional "low-prio" Backup- Thread - this thread will probably never finish - in case the other WorkerThreads perform writes against their (separate) SQLite-DB-ConnectionHandles. So, what we had planned for our AppServer was, to direct all DB-Write-Operations from the WorkerThreads to a dedicated DBWriterThread - which holds a separate DB-Handle too - but in case of a backup would pass its very same DB-Handle to the low-prio backupthread (thereby avoiding the retriggering). Do you see any chance (since all writes are already "centralized" if one uses the new async-writer-approach), that in case of a running "granular-backup" we could avoid our planned "workaround"? In either case - that will be a nice addition to the engine - thank you. Olaf Schmidt _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
