aboutsummaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authordrh <drh@noemail.net>2007-11-05 17:54:17 +0000
committerdrh <drh@noemail.net>2007-11-05 17:54:17 +0000
commitd64621d68d085b7b40813df14b406ec2c7cf08ba (patch)
tree66f51020f2c9b7f0de7a8e110a71619959505fa7 /src
parent7eb42c8204ba4ddc0e40178bbff7f76e8986232e (diff)
downloadsqlite-d64621d68d085b7b40813df14b406ec2c7cf08ba.tar.gz
sqlite-d64621d68d085b7b40813df14b406ec2c7cf08ba.zip
Drop support for the SQLITE_OMIT_MEMORY_ALLOCATION compile-time option. (CVS 4529)
FossilOrigin-Name: b57c89fed0b74c2e8fb68ccfdf5e5e7d4b2603a1
Diffstat (limited to 'src')
-rw-r--r--src/mem1.c5
-rw-r--r--src/mem2.c5
-rw-r--r--src/sqlite.h.in86
3 files changed, 21 insertions, 75 deletions
diff --git a/src/mem1.c b/src/mem1.c
index cfd29aa4e..9b221743c 100644
--- a/src/mem1.c
+++ b/src/mem1.c
@@ -12,7 +12,7 @@
** This file contains the C functions that implement a memory
** allocation subsystem for use by SQLite.
**
-** $Id: mem1.c,v 1.12 2007/10/19 17:47:25 drh Exp $
+** $Id: mem1.c,v 1.13 2007/11/05 17:54:17 drh Exp $
*/
/*
@@ -20,8 +20,7 @@
** used when no other memory allocator is specified using compile-time
** macros.
*/
-#if !defined(SQLITE_MEMDEBUG) && !defined(SQLITE_OMIT_MEMORY_ALLOCATION) \
- && !defined(SQLITE_MEMORY_SIZE)
+#if !defined(SQLITE_MEMDEBUG) && !defined(SQLITE_MEMORY_SIZE)
/*
** We will eventually construct multiple memory allocation subsystems
diff --git a/src/mem2.c b/src/mem2.c
index 0815a55ac..643f78955 100644
--- a/src/mem2.c
+++ b/src/mem2.c
@@ -12,7 +12,7 @@
** This file contains the C functions that implement a memory
** allocation subsystem for use by SQLite.
**
-** $Id: mem2.c,v 1.16 2007/10/19 17:47:25 drh Exp $
+** $Id: mem2.c,v 1.17 2007/11/05 17:54:17 drh Exp $
*/
/*
@@ -20,8 +20,7 @@
** SQLITE_MEMDEBUG macro is defined and SQLITE_OMIT_MEMORY_ALLOCATION
** is not defined.
*/
-#if defined(SQLITE_MEMDEBUG) && !defined(SQLITE_OMIT_MEMORY_ALLOCATION) \
- && !defined(SQLITE_MEMORY_SIZE)
+#if defined(SQLITE_MEMDEBUG) && !defined(SQLITE_MEMORY_SIZE)
/*
** We will eventually construct multiple memory allocation subsystems
diff --git a/src/sqlite.h.in b/src/sqlite.h.in
index c2cce7e34..cb1adf25e 100644
--- a/src/sqlite.h.in
+++ b/src/sqlite.h.in
@@ -30,7 +30,7 @@
** the version number) and changes its name to "sqlite3.h" as
** part of the build process.
**
-** @(#) $Id: sqlite.h.in,v 1.268 2007/10/27 16:25:16 drh Exp $
+** @(#) $Id: sqlite.h.in,v 1.269 2007/11/05 17:54:17 drh Exp $
*/
#ifndef _SQLITE3_H_
#define _SQLITE3_H_
@@ -1131,29 +1131,23 @@ char *sqlite3_snprintf(int,char*,const char*, ...);
**
** The SQLite core uses these three routines for all of its own
** internal memory allocation needs. (See the exception below.)
+**
** The default implementation
** of the memory allocation subsystem uses the malloc(), realloc()
** and free() provided by the standard C library. However, if
** SQLite is compiled with the following C preprocessor macro
**
-** <blockquote> SQLITE_OMIT_MEMORY_ALLOCATION </blockquote>
-**
-** then no implementation is provided for these routines by
-** SQLite. The application that links against SQLite is
-** expected to provide its own implementation. If the application
-** does provide its own implementation for these routines, then
-** it must also provide an implementations for
-** [sqlite3_memory_alarm()], [sqlite3_memory_used()], and
-** [sqlite3_memory_highwater()]. The alternative implementations
-** for these last three routines need not actually work, but
-** stub functions at least are needed to statisfy the linker.
-** SQLite never calls [sqlite3_memory_highwater()] itself, but
-** the symbol is included in a table as part of the
-** [sqlite3_load_extension()] interface. The
-** [sqlite3_memory_alarm()] and [sqlite3_memory_used()] interfaces
-** are called by [sqlite3_soft_heap_limit()] and working implementations
-** of both routines must be provided if [sqlite3_soft_heap_limit()]
-** is to operate correctly.
+** <blockquote> SQLITE_MEMORY_SIZE=<i>NNN</i> </blockquote>
+**
+** where <i>NNN</i> is an integer, then SQLite create a static
+** array of at least <i>NNN</i> bytes in size and use that array
+** for all of its dynamic memory allocation needs.
+**
+** In SQLite version 3.5.0 and 3.5.1, it was possible to define
+** the SQLITE_OMIT_MEMORY_ALLOCATION which would cause the built-in
+** implementation of these routines to be omitted. That capability
+** is no longer provided. Only built-in memory allocators can be
+** used.
**
** <b>Exception:</b> The windows OS interface layer calls
** the system malloc() and free() directly when converting
@@ -1181,55 +1175,14 @@ void sqlite3_free(void*);
** memory. The highwater mark is reset if the argument is
** true.
**
-** The implementation of these routines in the SQLite core
-** is omitted if the application is compiled with the
-** SQLITE_OMIT_MEMORY_ALLOCATION macro defined. In that case,
-** the application that links SQLite must provide its own
-** alternative implementation. See the documentation on
-** [sqlite3_malloc()] for additional information.
+** The value returned may or may not include allocation
+** overhead, depending on which built-in memory allocator
+** implementation is used.
*/
sqlite3_int64 sqlite3_memory_used(void);
sqlite3_int64 sqlite3_memory_highwater(int resetFlag);
/*
-** CAPI3REF: Memory Allocation Alarms
-**
-** The [sqlite3_memory_alarm] routine is used to register
-** a callback on memory allocation events.
-**
-** This routine registers or clears a callbacks that fires when
-** the amount of memory allocated exceeds iThreshold. Only
-** a single callback can be registered at a time. Each call
-** to [sqlite3_memory_alarm()] overwrites the previous callback.
-** The callback is disabled by setting xCallback to a NULL
-** pointer.
-**
-** The parameters to the callback are the pArg value, the
-** amount of memory currently in use, and the size of the
-** allocation that provoked the callback. The callback will
-** presumably invoke [sqlite3_free()] to free up memory space.
-** The callback may invoke [sqlite3_malloc()] or [sqlite3_realloc()]
-** but if it does, no additional callbacks will be invoked by
-** the recursive calls.
-**
-** The [sqlite3_soft_heap_limit()] interface works by registering
-** a memory alarm at the soft heap limit and invoking
-** [sqlite3_release_memory()] in the alarm callback. Application
-** programs should not attempt to use the [sqlite3_memory_alarm()]
-** interface because doing so will interfere with the
-** [sqlite3_soft_heap_limit()] module. This interface is exposed
-** only so that applications can provide their own
-** alternative implementation when the SQLite core is
-** compiled with SQLITE_OMIT_MEMORY_ALLOCATION.
-*/
-int sqlite3_memory_alarm(
- void(*xCallback)(void *pArg, sqlite3_int64 used, int N),
- void *pArg,
- sqlite3_int64 iThreshold
-);
-
-
-/*
** CAPI3REF: Compile-Time Authorization Callbacks
***
** This routine registers a authorizer callback with the SQLite library.
@@ -2324,6 +2277,7 @@ int sqlite3_expired(sqlite3_stmt*);
int sqlite3_transfer_bindings(sqlite3_stmt*, sqlite3_stmt*);
int sqlite3_global_recover(void);
void sqlite3_thread_cleanup(void);
+int sqlite3_memory_alarm(void(*)(void*,sqlite3_int64,int),void*,sqlite3_int64);
/*
** CAPI3REF: Obtaining SQL Function Parameter Values
@@ -2829,12 +2783,6 @@ int sqlite3_release_memory(int);
** continue without error or notification. This is why the limit is
** called a "soft" limit. It is advisory only.
**
-** The soft heap limit is implemented using the [sqlite3_memory_alarm()]
-** interface. Only a single memory alarm is available in the default
-** implementation. This means that if the application also uses the
-** memory alarm interface it will interfere with the operation of the
-** soft heap limit and undefined behavior will result.
-**
** Prior to SQLite version 3.5.0, this routine only constrained the memory
** allocated by a single thread - the same thread in which this routine
** runs. Beginning with SQLite version 3.5.0, the soft heap limit is