Adding upstream version 3.45.1.upstream/3.45.1

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
author: Daniel Baumann <daniel.baumann@progress-linux.org> 2024-04-13 14:07:11 +0000
committer: Daniel Baumann <daniel.baumann@progress-linux.org> 2024-04-13 14:07:11 +0000
commit: 63847496f14c813a5d80efd5b7de0f1294ffe1e3 (patch)
tree: 01c7571c7c762ceee70638549a99834fdd7c411b /www/asyncvfs.html
parent: Initial commit. (diff)
download: sqlite3-63847496f14c813a5d80efd5b7de0f1294ffe1e3.tar.xz
sqlite3-63847496f14c813a5d80efd5b7de0f1294ffe1e3.zip
1 files changed, 297 insertions, 0 deletions
diff --git a/www/asyncvfs.html b/www/asyncvfs.html
new file mode 100644
index 0000000..87e4a59
--- /dev/null
+++ b/www/asyncvfs.html
@@ -0,0 +1,297 @@
+<!DOCTYPE html>
+<html><head>
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
+<meta http-equiv="content-type" content="text/html; charset=UTF-8">
+<link href="sqlite.css" rel="stylesheet">
+<title>An Asynchronous I/O Module For SQLite</title>
+<!-- path= -->
+</head>
+<body>
+<div class=nosearch>
+<a href="index.html">
+<img class="logo" src="images/sqlite370_banner.gif" alt="SQLite" border="0">
+</a>
+<div><!-- IE hack to prevent disappearing logo --></div>
+<div class="tagline desktoponly">
+Small. Fast. Reliable.<br>Choose any three.
+</div>
+<div class="menu mainmenu">
+<ul>
+<li><a href="index.html">Home</a>
+<li class='mobileonly'><a href="javascript:void(0)" onclick='toggle_div("submenu")'>Menu</a>
+<li class='wideonly'><a href='about.html'>About</a>
+<li class='desktoponly'><a href="docs.html">Documentation</a>
+<li class='desktoponly'><a href="download.html">Download</a>
+<li class='wideonly'><a href='copyright.html'>License</a>
+<li class='desktoponly'><a href="support.html">Support</a>
+<li class='desktoponly'><a href="prosupport.html">Purchase</a>
+<li class='search' id='search_menubutton'>
+<a href="javascript:void(0)" onclick='toggle_search()'>Search</a>
+</ul>
+</div>
+<div class="menu submenu" id="submenu">
+<ul>
+<li><a href='about.html'>About</a>
+<li><a href='docs.html'>Documentation</a>
+<li><a href='download.html'>Download</a>
+<li><a href='support.html'>Support</a>
+<li><a href='prosupport.html'>Purchase</a>
+</ul>
+</div>
+<div class="searchmenu" id="searchmenu">
+<form method="GET" action="search">
+<select name="s" id="searchtype">
+<option value="d">Search Documentation</option>
+<option value="c">Search Changelog</option>
+</select>
+<input type="text" name="q" id="searchbox" value="">
+<input type="submit" value="Go">
+</form>
+</div>
+</div>
+<script>
+function toggle_div(nm) {
+var w = document.getElementById(nm);
+if( w.style.display=="block" ){
+w.style.display = "none";
+}else{
+w.style.display = "block";
+}
+}
+function toggle_search() {
+var w = document.getElementById("searchmenu");
+if( w.style.display=="block" ){
+w.style.display = "none";
+} else {
+w.style.display = "block";
+setTimeout(function(){
+document.getElementById("searchbox").focus()
+}, 30);
+}
+}
+function div_off(nm){document.getElementById(nm).style.display="none";}
+window.onbeforeunload = function(e){div_off("submenu");}
+/* Disable the Search feature if we are not operating from CGI, since */
+/* Search is accomplished using CGI and will not work without it. */
+if( !location.origin || !location.origin.match || !location.origin.match(/http/) ){
+document.getElementById("search_menubutton").style.display = "none";
+}
+/* Used by the Hide/Show button beside syntax diagrams, to toggle the */
+function hideorshow(btn,obj){
+var x = document.getElementById(obj);
+var b = document.getElementById(btn);
+if( x.style.display!='none' ){
+x.style.display = 'none';
+b.innerHTML='show';
+}else{
+x.style.display = '';
+b.innerHTML='hide';
+}
+return false;
+}
+var antiRobot = 0;
+function antiRobotGo(){
+if( antiRobot!=3 ) return;
+antiRobot = 7;
+var j = document.getElementById("mtimelink");
+if(j && j.hasAttribute("data-href")) j.href=j.getAttribute("data-href");
+}
+function antiRobotDefense(){
+document.body.onmousedown=function(){
+antiRobot |= 2;
+antiRobotGo();
+document.body.onmousedown=null;
+}
+document.body.onmousemove=function(){
+antiRobot |= 2;
+antiRobotGo();
+document.body.onmousemove=null;
+}
+setTimeout(function(){
+antiRobot |= 1;
+antiRobotGo();
+}, 100)
+antiRobotGo();
+}
+antiRobotDefense();
+</script>
+
+
+<h1 align="center">An Asynchronous I/O Module For SQLite</h1>
+
+<hr>
+<p><font size=+1><b>NOTE:</b> 
+<a href="wal.html">WAL mode</a> with <a href="pragma.html#pragma_synchronous">PRAGMA synchronous</a> set to NORMAL avoids calls to
+fsync() during transaction commit and only invokes fsync() during
+a <a href="wal.html#ckpt">checkpoint</a> operation.  The use of <a href="wal.html">WAL mode</a> largely obviates the
+need for this asynchronous I/O module.  Hence, this module is no longer
+supported.  The source code continues to exist in the SQLite source tree,
+but it is not a part of any standard build and is no longer maintained.
+This documentation is retained for historical reference.</font></p><hr>
+
+<p>Normally, when SQLite writes to a database file, it waits until the write
+operation is finished before returning control to the calling application.
+Since writing to the file-system is usually very slow compared with CPU
+bound operations, this can be a performance bottleneck. The asynchronous I/O
+backend is an extension that causes SQLite to perform all write requests
+using a separate thread running in the background. Although this does not
+reduce the overall system resources (CPU, disk bandwidth etc.), it does
+allow SQLite to return control to the caller quickly even when writing to
+the database.
+
+<h2>1.0 FUNCTIONALITY</h2>
+
+<p>With asynchronous I/O, write requests are handled by a separate thread
+running in the background.  This means that the thread that initiates
+a database write does not have to wait for (sometimes slow) disk I/O
+to occur.  The write seems to happen very quickly, though in reality
+it is happening at its usual slow pace in the background.
+
+<p>Asynchronous I/O appears to give better responsiveness, but at a price.
+You lose the Durable property.  With the default I/O backend of SQLite,
+once a write completes, you know that the information you wrote is
+safely on disk.  With the asynchronous I/O, this is not the case.  If
+your program crashes or if a power loss occurs after the database
+write but before the asynchronous write thread has completed, then the
+database change might never make it to disk and the next user of the
+database might not see your change.
+
+<p>You lose Durability with asynchronous I/O, but you still retain the
+other parts of ACID:  Atomic,  Consistent, and Isolated.  Many
+applications get along fine without the Durability.
+
+<h3>1.1 How it Works</h3>
+
+<p>Asynchronous I/O works by creating an SQLite <a href="c3ref/vfs.html">VFS object</a>
+and registering it with <a href="c3ref/vfs_find.html">sqlite3_vfs_register()</a>.
+When files opened via 
+this VFS are written to (using the vfs xWrite() method), the data is not 
+written directly to disk, but is placed in the "write-queue" to be
+handled by the background thread.
+
+<p>When files opened with the asynchronous VFS are read from 
+(using the vfs xRead() method), the data is read from the file on 
+disk and the write-queue, so that from the point of view of
+the vfs reader the xWrite() appears to have already completed.
+
+<p>The asynchronous I/O VFS is registered (and unregistered) by calls to the 
+API functions sqlite3async_initialize() and sqlite3async_shutdown().
+See section "Compilation and Usage" below for details.
+
+<h3>1.2 Limitations</h3>
+
+<p>In order to gain experience with the main ideas surrounding asynchronous 
+IO, this implementation is deliberately kept simple. Additional 
+capabilities may be added in the future.
+
+<p>For example, as currently implemented, if writes are happening at a 
+steady stream that exceeds the I/O capability of the background writer
+thread, the queue of pending write operations will grow without bound.
+If this goes on for long enough, the host system could run out of memory. 
+A more sophisticated module could to keep track of the quantity of 
+pending writes and stop accepting new write requests when the queue of 
+pending writes grows too large.
+
+<h3>1.3 Locking and Concurrency</h3>
+
+<p>Multiple connections from within a single process that use this
+implementation of asynchronous IO may access a single database
+file concurrently. From the point of view of the user, if all
+connections are from within a single process, there is no difference
+between the concurrency offered by "normal" SQLite and SQLite
+using the asynchronous backend.
+
+<p>If file-locking is enabled (it is enabled by default), then connections
+from multiple processes may also read and write the database file.
+However concurrency is reduced as follows:
+
+<ul>
+<li><p> When a connection using asynchronous IO begins a database
+        transaction, the database is locked immediately. However the
+        lock is not released until after all relevant operations
+        in the write-queue have been flushed to disk. This means
+        (for example) that the database may remain locked for some 
+        time after a "<a href="lang_transaction.html">COMMIT</a>" or "<a href="lang_transaction.html">ROLLBACK</a>" is issued.
+
+<li><p> If an application using asynchronous IO executes transactions
+        in quick succession, other database users may be effectively
+        locked out of the database. This is because when a <a href="lang_transaction.html">BEGIN</a>
+        is executed, a database lock is established immediately. But
+        when the corresponding COMMIT or ROLLBACK occurs, the lock
+        is not released until the relevant part of the write-queue 
+        has been flushed through. As a result, if a COMMIT is followed
+        by a BEGIN before the write-queue is flushed through, the database 
+        is never unlocked,preventing other processes from accessing 
+        the database.
+</ul>
+
+<p>File-locking may be disabled at runtime using the sqlite3async_control()
+API (see below). This may improve performance when an NFS or other 
+network file-system, as the synchronous round-trips to the server be 
+required to establish file locks are avoided. However, if multiple 
+connections attempt to access the same database file when file-locking
+is disabled, application crashes and database corruption is a likely
+outcome.
+
+
+<h2>2.0 COMPILATION AND USAGE</h2>
+
+<p>
+The asynchronous IO extension consists of a single file of C code
+(sqlite3async.c), and a header file (sqlite3async.h), located in the
+<a href="https://www.sqlite.org/src/dir?name=ext/async">
+<tt>ext/async/</tt> subfolder</a> of the SQLite source tree, that defines the 
+C API used by applications to activate and control the modules 
+functionality.
+
+<p>
+To use the asynchronous IO extension, compile sqlite3async.c as
+part of the application that uses SQLite. Then use the APIs defined
+in sqlite3async.h to initialize and configure the module.
+
+<p>
+The asynchronous IO VFS API is described in detail in comments in 
+sqlite3async.h. Using the API usually consists of the following steps:
+
+<ol>
+<li><p>Register the asynchronous IO VFS with SQLite by calling the
+       sqlite3async_initialize() function.
+
+<li><p>Create a background thread to perform write operations and call
+       sqlite3async_run().
+
+<li><p>Use the normal SQLite API to read and write to databases via 
+       the asynchronous IO VFS.
+</ol>
+
+<p>Refer to comments in the
+<a href="https://www.sqlite.org/src/finfo?name=ext/async/sqlite3async.h">
+sqlite3async.h header file</a> for details.
+
+
+<h2>3.0 PORTING</h2>
+
+<p>Currently the asynchronous IO extension is compatible with win32 systems
+and systems that support the pthreads interface, including Mac OS X, Linux, 
+and other varieties of Unix. 
+
+<p>To port the asynchronous IO extension to another platform, the user must
+implement mutex and condition variable primitives for the new platform.
+Currently there is no externally available interface to allow this, but
+modifying the code within sqlite3async.c to include the new platforms
+concurrency primitives is relatively easy. Search within sqlite3async.c
+for the comment string "PORTING FUNCTIONS" for details. Then implement
+new versions of each of the following:
+
+<blockquote><pre>
+static void async_mutex_enter(int eMutex);
+static void async_mutex_leave(int eMutex);
+static void async_cond_wait(int eCond, int eMutex);
+static void async_cond_signal(int eCond);
+static void async_sched_yield(void);
+</pre></blockquote>
+
+<p>The functionality required of each of the above functions is described
+in comments in sqlite3async.c.
+
+
author	Daniel Baumann <daniel.baumann@progress-linux.org>	2024-04-13 14:07:11 +0000
committer	Daniel Baumann <daniel.baumann@progress-linux.org>	2024-04-13 14:07:11 +0000
commit	63847496f14c813a5d80efd5b7de0f1294ffe1e3 (patch)
tree	01c7571c7c762ceee70638549a99834fdd7c411b /www/asyncvfs.html
parent	Initial commit. (diff)
download	sqlite3-63847496f14c813a5d80efd5b7de0f1294ffe1e3.tar.xz sqlite3-63847496f14c813a5d80efd5b7de0f1294ffe1e3.zip