Shutdown is not an option at all. I need vfs to continue working on other databases but to be notified (or have possibility to check) when one particular database is no longer opened.
Pavel On Thu, May 7, 2009 at 12:00 PM, Ken <kennethinbox-sql...@yahoo.com> wrote: > > --- On Thu, 5/7/09, Virgilio Alexandre Fornazin <virgilioforna...@gmail.com> > wrote: > >> From: Virgilio Alexandre Fornazin <virgilioforna...@gmail.com> >> Subject: Re: [sqlite] SQLite version 3.6.14 and async vfs >> To: "'General Discussion of SQLite Database'" <sqlite-users@sqlite.org> >> Date: Thursday, May 7, 2009, 10:50 AM >> Close should wait for all file >> operations complete to meet that needs. >> I think asynchronous VFS should take care of waiting in >> sqlite3_close() >> call. >> >> -----Original Message----- >> From: sqlite-users-boun...@sqlite.org >> [mailto:sqlite-users-boun...@sqlite.org] >> On Behalf Of Pavel Ivanov >> Sent: quinta-feira, 7 de maio de 2009 12:33 >> To: General Discussion of SQLite Database >> Subject: Re: [sqlite] SQLite version 3.6.14 and async vfs >> >> Hi! >> >> It's great to hear about performance improvements and >> especially about >> asynchronous I/O extension. Thank you very much for your >> work! >> >> I have one question though: taking quick look at the >> sources of async >> vfs I've noticed that even closing the file is just a task >> in the >> async queue and thus after closing sqlite connection file >> remains >> opened for some time. It sounds pretty reasonable, but here >> stands the >> question: what if I want to do something with the database >> file after >> I close sqlite connection to it (e.g. move to the archive >> directory, >> zip it etc.)? With sync vfs I could be sure that after >> closing >> connection file is closed and I can do with it whatever I >> want. Is >> there a way to catch the moment of actual file closing with >> async vfs? >> >> And another question just to be sure that I understand it >> correctly: >> async vfs holds only one queue for all opened database >> files, right? >> >> Pavel >> >> On Wed, May 6, 2009 at 10:36 PM, D. Richard Hipp <d...@hwaci.com> >> wrote: >> > SQLite version 3.6.14 is now available on the SQLite >> website >> > >> > http://www.sqlite.org/ >> > >> > Version 3.6.14 contains performance enhances in the >> btree and pager >> > subsystems. In addition, the query optimizer now >> knows how to take >> > advantage of OR and IN operators on columns of a >> virtual table. >> > >> > A new optional extension is included that implements >> an asynchronous I/ >> > O backend for SQLite on either windows or unix. The >> asynchronous I/O >> > backend processes all writes using a background >> thread. This gives >> > the appearance of faster response time at the cost of >> durability and >> > additional memory usage. See http://www.sqlite.org/asyncvfs.html for >> > additional information. >> > >> > This release also includes many small bug fixes and >> documentation >> > improvements. >> > >> > As always, please let me know if you encounter any >> difficulties. >> > >> > D. Richard Hipp >> > d...@hwaci.com >> > >> > > > Without actually looking at the async code I think that instead of using the > sqlite3_close to cause a block there should be a "shutdown" that would wait > for the shutdown of the async thread to complete. So maybe a better name > would be sqlite3Async_close or something similar. > > Ken > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
