On May 7, 2009, at 10:33 PM, Pavel Ivanov wrote: > 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?
Not easily. With the current code you could call sqlite3async_control() to configure the background thread to return when the write-queue is empty (SQLITEASYNC_HALT_IDLE). When the call to sqlite3async_run() returns you can be sure that the queue is empty and thus any close-file operation must have been flushed through. > And another question just to be sure that I understand it correctly: > async vfs holds only one queue for all opened database files, right? True statement. Dan. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
