Index: src/mutex_unix.c
==================================================================
--- src/mutex_unix.c
+++ src/mutex_unix.c
@@ -89,10 +89,11 @@
**
SQLITE_MUTEX_STATIC_MASTER
** SQLITE_MUTEX_STATIC_MEM
** SQLITE_MUTEX_STATIC_MEM2
** SQLITE_MUTEX_STATIC_PRNG
** SQLITE_MUTEX_STATIC_LRU
+** SQLITE_MUTEX_STATIC_LRU2
**
**
** The first two constants cause sqlite3_mutex_alloc() to create
** a new mutex. The new mutex is recursive when SQLITE_MUTEX_RECURSIVE
** is used but not necessarily so when SQLITE_MUTEX_FAST is used.
@@ -102,11 +103,11 @@
** cases where it really needs one. If a faster non-recursive mutex
** implementation is available on the host platform, the mutex subsystem
** might return such a mutex in response to SQLITE_MUTEX_FAST.
**
** The other allowed parameters to sqlite3_mutex_alloc() each return
-** a pointer to a static preexisting mutex. Three static mutexes are
+** a pointer to a static preexisting mutex. Six static mutexes are
** used by the current version of SQLite. Future versions of SQLite
** may add additional static mutexes. Static mutexes are for internal
** use by SQLite only. Applications that use SQLite mutexes should
** use only the dynamic mutexes returned by SQLITE_MUTEX_FAST or
** SQLITE_MUTEX_RECURSIVE.
Index: src/mutex_w32.c
==================================================================
--- src/mutex_w32.c
+++ src/mutex_w32.c
@@ -129,15 +129,18 @@
** that means that a mutex could not be allocated. SQLite
** will unwind its stack and return an error. The argument
** to sqlite3_mutex_alloc() is one of these integer constants:
**
**
-** - SQLITE_MUTEX_FAST 0
-**
- SQLITE_MUTEX_RECURSIVE 1
-**
- SQLITE_MUTEX_STATIC_MASTER 2
-**
- SQLITE_MUTEX_STATIC_MEM 3
-**
- SQLITE_MUTEX_STATIC_PRNG 4
+**
- SQLITE_MUTEX_FAST
+**
- SQLITE_MUTEX_RECURSIVE
+**
- SQLITE_MUTEX_STATIC_MASTER
+**
- SQLITE_MUTEX_STATIC_MEM
+**
- SQLITE_MUTEX_STATIC_MEM2
+**
- SQLITE_MUTEX_STATIC_PRNG
+**
- SQLITE_MUTEX_STATIC_LRU
+**
- SQLITE_MUTEX_STATIC_LRU2
**
**
** The first two constants cause sqlite3_mutex_alloc() to create
** a new mutex. The new mutex is recursive when SQLITE_MUTEX_RECURSIVE
** is used but not necessarily so when SQLITE_MUTEX_FAST is used.
@@ -147,11 +150,11 @@
** cases where it really needs one. If a faster non-recursive mutex
** implementation is available on the host platform, the mutex subsystem
** might return such a mutex in response to SQLITE_MUTEX_FAST.
**
** The other allowed parameters to sqlite3_mutex_alloc() each return
-** a pointer to a static preexisting mutex. Three static mutexes are
+** a pointer to a static preexisting mutex. Six static mutexes are
** used by the current version of SQLite. Future versions of SQLite
** may add additional static mutexes. Static mutexes are for internal
** use by SQLite only. Applications that use SQLite mutexes should
** use only the dynamic mutexes returned by SQLITE_MUTEX_FAST or
** SQLITE_MUTEX_RECURSIVE.
Index: src/pcache1.c
==================================================================
--- src/pcache1.c
+++ src/pcache1.c
@@ -410,10 +410,12 @@
return SQLITE_OK;
}
/*
** Implementation of the sqlite3_pcache.xShutdown method.
+** Note that the static mutex allocated in xInit does
+** not need to be freed.
*/
static void pcache1Shutdown(void *NotUsed){
UNUSED_PARAMETER(NotUsed);
assert( pcache1.isInit!=0 );
memset(&pcache1, 0, sizeof(pcache1));
Index: src/sqlite.h.in
==================================================================
--- src/sqlite.h.in
+++ src/sqlite.h.in
@@ -16,12 +16,12 @@
** notice, and should not be referenced by programs that use SQLite.
**
** Some of the definitions that are in this file are marked as
** "experimental". Experimental interfaces are normally new
** features recently added to SQLite. We do not anticipate changes
-** to experimental interfaces but reserve to make minor changes if
-** experience from use "in the wild" suggest such changes are prudent.
+** to experimental interfaces but reserve the right to make minor changes
+** if experience from use "in the wild" suggest such changes are prudent.
**
** The official C-language API documentation for SQLite is derived
** from comments in this file. This file is the authoritative source
** on how SQLite interfaces are suppose to operate.
**
@@ -50,11 +50,11 @@
#endif
/*
** These no-op macros are used in front of interfaces to mark those
** interfaces as either deprecated or experimental. New applications
-** should not use deprecated intrfaces - they are support for backwards
+** should not use deprecated interfaces - they are support for backwards
** compatibility only. Application writers should be aware that
** experimental interfaces are subject to change in point releases.
**
** These macros used to resolve to various kinds of compiler magic that
** would generate warning messages when they were used. But that
@@ -857,11 +857,11 @@
** or sqlite3_os_end() directly. The application should only invoke
** sqlite3_initialize() and sqlite3_shutdown(). The sqlite3_os_init()
** interface is called automatically by sqlite3_initialize() and
** sqlite3_os_end() is called by sqlite3_shutdown(). Appropriate
** implementations for sqlite3_os_init() and sqlite3_os_end()
-** are built into SQLite when it is compiled for unix, windows, or os/2.
+** are built into SQLite when it is compiled for Unix, Windows, or OS/2.
** When built for other platforms (using the [SQLITE_OS_OTHER=1] compile-time
** option) the application must supply a suitable implementation for
** sqlite3_os_init() and sqlite3_os_end(). An application-supplied
** implementation of sqlite3_os_init() or sqlite3_os_end()
** must return [SQLITE_OK] on success and some other [error code] upon
@@ -1594,11 +1594,11 @@
void sqlite3_free_table(char **result);
/*
** CAPI3REF: Formatted String Printing Functions {H17400}
**
-** These routines are workalikes of the "printf()" family of functions
+** These routines are work-alikes of the "printf()" family of functions
** from the standard C library.
**
** The sqlite3_mprintf() and sqlite3_vmprintf() routines write their
** results into memory obtained from [sqlite3_malloc()].
** The strings returned by these two routines should be
@@ -1881,11 +1881,11 @@
** the database connection that invoked the authorizer callback.
** Note that [sqlite3_prepare_v2()] and [sqlite3_step()] both modify their
** database connections for the meaning of "modify" in this paragraph.
**
** When [sqlite3_prepare_v2()] is used to prepare a statement, the
-** statement might be reprepared during [sqlite3_step()] due to a
+** statement might be re-prepared during [sqlite3_step()] due to a
** schema change. Hence, the application should ensure that the
** correct authorizer callback remains in place during the [sqlite3_step()].
**
** Note that the authorizer callback is invoked only during
** [sqlite3_prepare()] or its variants. Authorization is not
@@ -4714,11 +4714,11 @@
** cases where it really needs one. {END} If a faster non-recursive mutex
** implementation is available on the host platform, the mutex subsystem
** might return such a mutex in response to SQLITE_MUTEX_FAST.
**
** {H17017} The other allowed parameters to sqlite3_mutex_alloc() each return
-** a pointer to a static preexisting mutex. {END} Four static mutexes are
+** a pointer to a static preexisting mutex. {END} Six static mutexes are
** used by the current version of SQLite. Future versions of SQLite
** may add additional static mutexes. Static mutexes are for internal
** use by SQLite only. Applications that use SQLite mutexes should
** use only the dynamic mutexes returned by SQLITE_MUTEX_FAST or
** SQLITE_MUTEX_RECURSIVE.
@@ -5206,28 +5206,39 @@
** EXPERIMENTAL
**
** The [sqlite3_config]([SQLITE_CONFIG_PCACHE], ...) interface can
** register an alternative page cache implementation by passing in an
** instance of the sqlite3_pcache_methods structure. The majority of the
-** heap memory used by sqlite is used by the page cache to cache data read
+** heap memory used by SQLite is used by the page cache to cache data read
** from, or ready to be written to, the database file. By implementing a
** custom page cache using this API, an application can control more
-** precisely the amount of memory consumed by sqlite, the way in which
+** precisely the amount of memory consumed by SQLite, the way in which
** said memory is allocated and released, and the policies used to
** determine exactly which parts of a database file are cached and for
** how long.
**
-** The contents of the structure are copied to an internal buffer by sqlite
+** The contents of the structure are copied to an internal buffer by SQLite
** within the call to [sqlite3_config].
**
** The xInit() method is called once for each call to [sqlite3_initialize()]
** (usually only once during the lifetime of the process). It is passed
** a copy of the sqlite3_pcache_methods.pArg value. It can be used to set
** up global structures and mutexes required by the custom page cache
-** implementation. The xShutdown() method is called from within
-** [sqlite3_shutdown()], if the application invokes this API. It can be used
-** to clean up any outstanding resources before process shutdown, if required.
+** implementation.
+**
+** The xShutdown() method is called from within [sqlite3_shutdown()],
+** if the application invokes this API. It can be used to clean up
+** any outstanding resources before process shutdown, if required.
+**
+** SQLite holds a [SQLITE_MUTEX_RECURSIVE] mutex when it invokes
+** the xInit method, so the xInit method need not be threadsafe. The
+** xShutdown method is only called from [sqlite3_shutdown()] so it does
+** not need to be threadsafe either. All other methods must be threadsafe
+** in multithreaded applications.
+**
+** SQLite will never invoke xInit() more than once without an intervening
+** call to xShutdown().
**
** The xCreate() method is used to construct a new cache instance. The
** first parameter, szPage, is the size in bytes of the pages that must
** be allocated by the cache. szPage will not be a power of two. The
** second argument, bPurgeable, is true if the cache being created will