Re: [sqlite] SQLite version 3.6.14 and async vfs
Obviously i had not looked at the code. I see now that the async code is registered as a VFS... And thanks to Dan there is only one background thread and queue. One could implement the background thread and a function, mutex and condition variable so that the function would call the sqlite3async_control setting the SQLITEASYNC_HALT_IDLE. The function would then block on the condition awaiting the running thread to complete the work. The running thread would then signal the condition causing the "waiting" function to return. --- On Thu, 5/7/09, Virgilio Alexandre Fornazin wrote: > From: Virgilio Alexandre Fornazin > Subject: RE: [sqlite] SQLite version 3.6.14 and async vfs > To: kennethinbox-sql...@yahoo.com, "'General Discussion of SQLite Database'" > , "'Pavel Ivanov'" > Date: Thursday, May 7, 2009, 12:04 PM > This break purpose of VFS, all VFS > should work in same way, you must not > know if your VFS is asynchronous > or not. VFS close method should wait for all file I/O on > this database > handle (not all databases) to > finalize before returning, providing compatibility with all > other existing > VFS implementations. > > > -Original Message- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org] > On Behalf Of Ken > Sent: quinta-feira, 7 de maio de 2009 13:47 > To: General Discussion of SQLite Database; Pavel Ivanov > Subject: Re: [sqlite] SQLite version 3.6.14 and async vfs > > > I see the confusion with the word "Shutdown". > > How about but a call that would block until the async > thread completes all > operations that are enqueued. Effectively a Close of the > async thread/queue > and db. The call could be sqlite3Async_close. > > Hope that clarifies my intent. > > > --- On Thu, 5/7/09, Pavel Ivanov > wrote: > > > From: Pavel Ivanov > > Subject: Re: [sqlite] SQLite version 3.6.14 and async > vfs > > To: kennethinbox-sql...@yahoo.com, > "General Discussion of SQLite Database" > > > Date: Thursday, May 7, 2009, 11:10 AM > > 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 > > wrote: > > > > > > --- On Thu, 5/7/09, Virgilio Alexandre Fornazin > > > wrote: > > > > > >> From: Virgilio Alexandre Fornazin > > >> Subject: Re: [sqlite] SQLite version 3.6.14 > and > > async vfs > > >> To: "'General Discussion of SQLite > Database'" > > > > >> 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 > > >&g
Re: [sqlite] SQLite version 3.6.14 and async vfs
This break purpose of VFS, all VFS should work in same way, you must not know if your VFS is asynchronous or not. VFS close method should wait for all file I/O on this database handle (not all databases) to finalize before returning, providing compatibility with all other existing VFS implementations. -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Ken Sent: quinta-feira, 7 de maio de 2009 13:47 To: General Discussion of SQLite Database; Pavel Ivanov Subject: Re: [sqlite] SQLite version 3.6.14 and async vfs I see the confusion with the word "Shutdown". How about but a call that would block until the async thread completes all operations that are enqueued. Effectively a Close of the async thread/queue and db. The call could be sqlite3Async_close. Hope that clarifies my intent. --- On Thu, 5/7/09, Pavel Ivanov wrote: > From: Pavel Ivanov > Subject: Re: [sqlite] SQLite version 3.6.14 and async vfs > To: kennethinbox-sql...@yahoo.com, "General Discussion of SQLite Database" > Date: Thursday, May 7, 2009, 11:10 AM > 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 > wrote: > > > > --- On Thu, 5/7/09, Virgilio Alexandre Fornazin > wrote: > > > >> From: Virgilio Alexandre Fornazin > >> Subject: Re: [sqlite] SQLite version 3.6.14 and > async vfs > >> To: "'General Discussion of SQLite Database'" > > >> 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 > > >> 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 > >> > additi
Re: [sqlite] SQLite version 3.6.14 and async vfs
According to the fact that queue in async vfs is one for all databases and along with closing of one database there could be some writings to another ones, method of catching the return from sqlite3async_run() can be significantly delayed if work at all... Ok, thank you for the extension anyway. I will think what can I do in this situation. Pavel On Thu, May 7, 2009 at 12:54 PM, Dan wrote: > > 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 > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite version 3.6.14 and async vfs
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
Re: [sqlite] SQLite version 3.6.14 and async vfs
I see the confusion with the word "Shutdown". How about but a call that would block until the async thread completes all operations that are enqueued. Effectively a Close of the async thread/queue and db. The call could be sqlite3Async_close. Hope that clarifies my intent. --- On Thu, 5/7/09, Pavel Ivanov wrote: > From: Pavel Ivanov > Subject: Re: [sqlite] SQLite version 3.6.14 and async vfs > To: kennethinbox-sql...@yahoo.com, "General Discussion of SQLite Database" > > Date: Thursday, May 7, 2009, 11:10 AM > 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 > wrote: > > > > --- On Thu, 5/7/09, Virgilio Alexandre Fornazin > wrote: > > > >> From: Virgilio Alexandre Fornazin > >> Subject: Re: [sqlite] SQLite version 3.6.14 and > async vfs > >> To: "'General Discussion of SQLite Database'" > > >> 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 > > >> 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
Re: [sqlite] SQLite version 3.6.14 and async vfs
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 wrote: > > --- On Thu, 5/7/09, Virgilio Alexandre Fornazin > wrote: > >> From: Virgilio Alexandre Fornazin >> Subject: Re: [sqlite] SQLite version 3.6.14 and async vfs >> To: "'General Discussion of SQLite Database'" >> 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 >> 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
Re: [sqlite] SQLite version 3.6.14 and async vfs
--- On Thu, 5/7/09, Virgilio Alexandre Fornazin wrote: > From: Virgilio Alexandre Fornazin > Subject: Re: [sqlite] SQLite version 3.6.14 and async vfs > To: "'General Discussion of SQLite Database'" > 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 > 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
Re: [sqlite] SQLite version 3.6.14 and async vfs
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 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 > > > > ___ > 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 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
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 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 > > > > ___ > 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
