8000 update to upstream sqlite 3.6.14 · codeguru85/sqlcipher@7fa2106 · GitHub
[go: up one dir, main page]
Skip to content

Commit 7fa2106

Browse files
sjlombardosjlombardo
committed
update to upstream sqlite 3.6.14
1 parent 81f606f commit 7fa2106

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

104 files changed

+33145
-22307
lines changed

‎Makefile.vxworks

Lines changed: 35 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -188,19 +188,24 @@ NAWK = awk
188188

189189
# This is how we compile
190190
#
191-
TCCX = $(TCC) $(OPTS) -I. -I$(TOP)/src -I$(TOP) -I$(TOP)/ext/rtree
192-
TCCX_SHARED = $(TCC_SHARED) $(OPTS) -I. -I$(TOP)/src -I$(TOP) -I$(TOP)/ext/rtree
191+
TCCX = $(TCC) $(OPTS) -I. -I$(TOP)/src -I$(TOP)
192+
TCCX_SHARED = $(TCC_SHARED) $(OPTS) -I. -I$(TOP)/src -I$(TOP) \
193+
-I$(TOP)/ext/rtree -I$(TOP)/ext/icu -I$(TOP)/ext/fts3 \
194+
-I$(TOP)/ext/async
193195

194196
# Object files for the SQLite library.
195197
#
196198
LIBOBJ+= alter.o analyze.o attach.o auth.o \
197199
backup.o bitvec.o btmutex.o btree.o build.o \
198-
callback.o complete.o date.o delete.o \
199-
expr.o fault.o func.o global.o hash.o \
200+
callback.o complete.o date.o delete.o expr.o fault.o \
201+
fts3.o fts3_expr.o fts3_hash.o fts3_icu.o fts3_porter.o \
202+
fts3_tokenizer.o fts3_tokenizer1.o \
203+
func.o global.o hash.o \
200204
icu.o insert.o journal.o legacy.o loadext.o \
201-
main.o malloc.o mem0.o mem1.o mem2.o mem3.o mem5.o memjournal.o \
202-
mutex.o mutex_os2.o mutex_unix.o mutex_w32.o mutex_noop.o \
203-
opcodes.o os.o os_os2.o os_unix.o os_win.o \
205+
main.o malloc.o mem0.o mem1.o mem2.o mem3.o mem5.o \
206+
memjournal.o \
207+
mutex.o mutex_noop.o mutex_os2.o mutex_unix.o mutex_w32.o \
208+
notify.o opcodes.o os.o os_os2.o os_unix.o os_win.o \
204209
pager.o parse.o pcache.o pcache1.o pragma.o prepare.o printf.o \
205210
random.o resolve.o rowset.o rtree.o select.o status.o \
206211
table.o tokenize.o trigger.o \
@@ -209,6 +214,7 @@ LIBOBJ+= alter.o analyze.o attach.o auth.o \
209214
walker.o where.o utf.o vtab.o
210215

211216

217+
212218
# All of the source code files.
213219
#
214220
SRC = \
@@ -248,10 +254,11 @@ SRC = \
248254
$(TOP)/src/memjournal.c \
249255
$(TOP)/src/mutex.c \
250256
$(TOP)/src/mutex.h \
257+
$(TOP)/src/mutex_noop.c \
251258
$(TOP)/src/mutex_os2.c \
252259
$(TOP)/src/mutex_unix.c \
253260
$(TOP)/src/mutex_w32.c \
254-
$(TOP)/src/mutex_noop.c \
261+
$(TOP)/src/notify.c \
255262
$(TOP)/src/os.c \
256263
$(TOP)/src/os.h \
257264
$(TOP)/src/os_common.h \
@@ -262,8 +269,8 @@ SRC = \
262269
$(TOP)/src/pager.h \
263270
$(TOP)/src/parse.y \
264271
$(TOP)/src/pcache.c \
265-
$(TOP)/src/pcache1.c \
266272
$(TOP)/src/pcache.h \
273+
$(TOP)/src/pcache1.c \
267274
$(TOP)/src/pragma.c \
268275
$(TOP)/src/prepare.c \
269276
$(TOP)/src/printf.c \
@@ -329,8 +336,8 @@ SRC += \
329336
$(TOP)/ext/fts3/fts3_tokenizer.c \
330337
$(TOP)/ext/fts3/fts3_tokenizer1.c
331338
SRC += \
332-
$(TOP)/ext/icu/icu.c \
333-
$(TOP)/ext/icu/sqliteicu.h
339+
$(TOP)/ext/icu/sqliteicu.h \
340+
$(TOP)/ext/icu/icu.c
334341
SRC += \
335342
$(TOP)/ext/rtree/rtree.h \
336343
$(TOP)/ext/rtree/rtree.c
@@ -361,33 +368,41 @@ TESTSRC = \
361368
$(TOP)/src/test9.c \
362369
$(TOP)/src/test_autoext.c \
363370
$(TOP)/src/test_async.c \
371+
$(TOP)/src/test_backup.c \
364372
$(TOP)/src/test_btree.c \
365373
$(TOP)/src/test_config.c \
366374
$(TOP)/src/test_devsym.c \
367375
$(TOP)/src/test_func.c \
368376
$(TOP)/src/test_hexio.c \
377+
$(TOP)/src/test_journal.c \
369378
$(TOP)/src/test_malloc.c \
370379
$(TOP)/src/test_md5.c \
371380
$(TOP)/src/test_mutex.c \
372381
$(TOP)/src/test_onefile.c \
373382
$(TOP)/src/test_osinst.c \
383+
$(TOP)/src/test_pcache.c \
374384
$(TOP)/src/test_schema.c \
375385
$(TOP)/src/test_server.c \
376386
$(TOP)/src/test_tclvar.c \
377387
$(TOP)/src/test_thread.c \
388+
$(TOP)/src/test_wsd.c \
378389

379390
#TESTSRC += $(TOP)/ext/fts2/fts2_tokenizer.c
380391
#TESTSRC += $(TOP)/ext/fts3/fts3_tokenizer.c
381392

382393
TESTSRC2 = \
383-
$(TOP)/src/attach.c $(TOP)/src/btree.c $(TOP)/src/build.c $(TOP)/src/date.c \
394+
$(TOP)/src/attach.c $(TOP)/src/backup.c $(TOP)/src/btree.c \
395+
$(TOP)/src/build.c $(TOP)/src/date.c \
384396
$(TOP)/src/expr.c $(TOP)/src/func.c $(TOP)/src/insert.c $(TOP)/src/os.c \
385397
$(TOP)/src/os_os2.c $(TOP)/src/os_unix.c $(TOP)/src/os_win.c \
386398
$(TOP)/src/pager.c $(TOP)/src/pragma.c $(TOP)/src/prepare.c \
387399
$(TOP)/src/printf.c $(TOP)/src/random.c $(TOP)/src/pcache.c \
388-
$(TOP)/src/select.c $(TOP)/src/tokenize.c \
400+
$(TOP)/src/pcache1.c $(TOP)/src/select.c $(TOP)/src/tokenize.c \
389401
$(TOP)/src/utf.c $(TOP)/src/util.c $(TOP)/src/vdbeapi.c $(TOP)/src/vdbeaux.c \
390-
$(TOP)/src/vdbe.c $(TOP)/src/vdbemem.c $(TOP)/src/where.c parse.c
402+
$(TOP)/src/vdbe.c $(TOP)/src/vdbemem.c $(TOP)/src/where.c parse.c \
403+
$(TOP)/ext/fts3/fts3.c $(TOP)/ext/fts3/fts3_expr.c \
404+
$(TOP)/ext/fts3/fts3_tokenizer.c \
405+
$(TOP)/ext/async/sqlite3async.c
391406

392407
# Header files used by all library source files.
393408
#
@@ -423,10 +438,13 @@ EXTHDR += \
423438
$(TOP)/ext/fts2/fts2_tokenizer.h
424439
EXTHDR += \
425440
$(TOP)/ext/fts3/fts3.h \
441+
$(TOP)/ext/fts3/fts3_expr.h \
426442
$(TOP)/ext/fts3/fts3_hash.h \
427443
$(TOP)/ext/fts3/fts3_tokenizer.h
428444
EXTHDR += \
429445
$(TOP)/ext/rtree/rtree.h
446+
EXTHDR += \
447+
$(TOP)/ext/icu/sqliteicu.h
430448

431449
# This is the default Makefile target. The objects listed here
432450
# are what get build when you type just "make" with no arguments.
@@ -551,6 +569,9 @@ fts2_tokenizer1.o: $(TOP)/ext/fts2/fts2_tokenizer1.c $(HDR) $(EXTHDR)
551569
fts3.o: $(TOP)/ext/fts3/fts3.c $(HDR) $(EXTHDR)
552570
$(TCCX_SHARED) -DSQLITE_CORE -c $(TOP)/ext/fts3/fts3.c
553571

572+
fts3_expr.o: $(TOP)/ext/fts3/fts3_expr.c $(HDR) $(EXTHDR)
573+
$(TCCX_SHARED) -DSQLITE_CORE -c $(TOP)/ext/fts3/fts3_expr.c
574+
554575
fts3_hash.o: $(TOP)/ext/fts3/fts3_hash.c $(HDR) $(EXTHDR)
555576
$(TCCX_SHARED) -DSQLITE_CORE -c $(TOP)/ext/fts3/fts3_hash.c
556577

‎VERSION

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
3.6.13
1+
3.6.14

‎configure.ac

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -90,7 +90,7 @@
9090
AC_INIT(sqlite, m4_esyscmd([cat VERSION | tr -d '\n']))
9191

9292
dnl Make sure the local VERSION file matches this configure script
93-
sqlite_version_sanity_check=`cat VERSION | tr -d '\n'`
93+
sqlite_version_sanity_check=`cat $srcdir/VERSION | tr -d '\n'`
9494
if test "$PACKAGE_VERSION" != "$sqlite_version_sanity_check" ; then
9595
AC_MSG_ERROR([configure script is out of date:
9696
configure \$PACKAGE_VERSION = $PACKAGE_VERSION
@@ -101,7 +101,7 @@ fi
101101
dnl Put the RCS revision string after AC_INIT so that it will also
102102
dnl show in in configure.
103103
# The following RCS revision string applies to configure.in
104-
# $Revision: 1.55 $
104+
# $Revision: 1.56 $
105105

106106
#########
107107
# Programs needed

‎ext/async/README.txt

Lines changed: 164 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,164 @@
1+
2+
Normally, when SQLite writes to a database file, it waits until the write
3+
operation is finished before returning control to the calling application.
4+
Since writing to the file-system is usually very slow compared with CPU
5+
bound operations, this can be a performance bottleneck. This directory
6+
contains an extension that causes SQLite to perform all write requests
7+
using a separate thread running in the background. Although this does not
8+
reduce the overall system resources (CPU, disk bandwidth etc.) at all, it
9+
allows SQLite to return control to the caller quickly even when writing to
10+
the database, eliminating the bottleneck.
11+
12+
1. Functionality
13+
14+
1.1 How it Works
15+
1.2 Limitations
16+
1.3 Locking and Concurrency
17+
18+
2. Compilation and Usage
19+
20+
3. Porting
21+
22+
23+
24+
1. FUNCTIONALITY
25+
26+
With asynchronous I/O, write requests are handled by a separate thread
27+
running in the background. This means that the thread that initiates
28+
a database write does not have to wait for (sometimes slow) disk I/O
29+
to occur. The write seems to happen very quickly, though in reality
30+
it is happening at its usual slow pace in the background.
31+
32+
Asynchronous I/O appears to give better responsiveness, but at a price.
33+
You lose the Durable property. With the default I/O backend of SQLite,
34+
once a write completes, you know that the information you wrote is
35+
safely on disk. With the asynchronous I/O, this is not the case. If
36+
your program crashes or if a power loss occurs after the database
37+
write but before the asynchronous write thread has completed, then the
38+
database change might never make it to disk and the next user of the
39+
database might not see your change.
40+
41+
You lose Durability with asynchronous I/O, but you still retain the
42+
other parts of ACID: Atomic, Consistent, and Isolated. Many
43+
appliations get along fine without the Durablity.
44+
45+
1.1 How it Works
46+
47+
Asynchronous I/O works by creating a special SQLite "vfs" structure
48+
and registering it with sqlite3_vfs_register(). When files opened via
49+
this vfs are written to (using the vfs xWrite() method), the data is not
50+
written directly to disk, but is placed in the "write-queue" to be
51+
handled by the background thread.
52+
53+
When files opened with the asynchronous vfs are read from
54+
(using the vfs xRead() method), the data is read from the file on
55+
disk and the write-queue, so that from the point of view of
56+
the vfs reader the xWrite() appears to have already completed.
57+
58+
The special vfs is registered (and unregistered) by calls to the
59+
API functions sqlite3async_initialize() and sqlite3async_shutdown().
60+
See section "Compilation and Usage" below for details.
61+
62+
1.2 Limitations
63+
64+
In order to gain experience with the main ideas surrounding asynchronous
65+
IO, this implementation is deliberately kept simple. Additional
66+
capabilities may be added in the future.
67+
68+
For example, as currently implemented, if writes are happening at a
69+
steady stream that exceeds the I/O capability of the background writer
70+
thread, the queue of pending write operations will grow without bound.
71+
If this goes on for long enough, the host system could run out of memory.
72+
A more sophisticated module could to keep track of the quantity of
73+
pending writes and stop accepting new write requests when the queue of
74+
pending writes grows too large.
75+
76+
1.3 Locking and Concurrency
77+
78+
Multiple connections from within a single process that use this
79+
implementation of asynchronous IO may access a single database
80+
file concurrently. From the point of view of the user, if all
81+
connections are from within a single process, there is no difference
82+
between the concurrency offered by "normal" SQLite and SQLite
83+
using the asynchronous backend.
84+
85+
If file-locking is enabled (it is enabled by default), then connections
86+
from multiple processes may also read and write the database file.
87+
However concurrency is reduced as follows:
88+
89+
* When a connection using asynchronous IO begins a database
90+
transaction, the database is locked immediately. However the
91+
lock is not released until after all relevant operations
92+
in the write-queue have been flushed to disk. This means
93+
(for example) that the database may remain locked for some
94+
time after a "COMMIT" or "ROLLBACK" is issued.
95+
96+
* If an application using asynchronous IO executes transactions
97+
in quick succession, other database users may be effectively
98+
locked out of the database. This is because when a BEGIN
99+
is executed, a database lock is established immediately. But
100+
when the corresponding COMMIT or ROLLBACK occurs, the lock
101+
is not released until the relevant part of the write-queue
102+
has been flushed through. As a result, if a COMMIT is followed
103+
by a BEGIN before the write-queue is flushed through, the database
104+
is never unlocked,preventing other processes from accessing
105+
the database.
106+
107+
File-locking may be disabled at runtime using the sqlite3async_control()
108+
API (see below). This may improve performance when an NFS or other
109+
network file-system, as the synchronous round-trips to the server be
110+
required to establish file locks are avoided. However, if multiple
111+
connections attempt to access the same database file when file-locking
112+
is disabled, application crashes and database corruption is a likely
113+
outcome.
114+
115+
116+
2. COMPILATION AND USAGE
117+
118+
The asynchronous IO extension consists of a single file of C code
119+
(sqlite3async.c), and a header file (sqlite3async.h) that defines the
120+
C API used by applications to activate and control the modules
121+
functionality.
122+
123+
To use the asynchronous IO extension, compile sqlite3async.c as
124+
part of the application that uses SQLite. Then use the API defined
125+
in sqlite3async.h to initialize and configure the module.
126+
127+
The asynchronous IO VFS API is described in detail in comments in
128+
sqlite3async.h. Using the API usually consists of the following steps:
129+
130+
1. Register the asynchronous IO VFS with SQLite by calling the
131+
sqlite3async_initialize() function.
132+
133+
2. Create a background thread to perform write operations and call
134+
sqlite3async_run().
135+
136+
3. Use the normal SQLite API to read and write to databases via
137+
the asynchronous IO VFS.
138+
139+
Refer to sqlite3async.h for details.
140+
141+
142+
3. PORTING
143+
144+
Currently the asynchronous IO extension is compatible with win32 systems
145+
and systems that support the pthreads interface, including Mac OSX, Linux,
146+
and other varieties of Unix.
147+
148+
To port the asynchronous IO extension to another platform, the user must
149+
implement mutex and condition variable primitives for the new platform.
150+
Currently there is no externally available interface to allow this, but
151+
modifying the code within sqlite3async.c to include the new platforms
152+
concurrency primitives is relatively easy. Search within sqlite3async.c
153+
for the comment string "PORTING FUNCTIONS" for details. Then implement
154+
new versions of each of the following:
155+
156+
static void async_mutex_enter(int eMutex);
157+
static void async_mutex_leave(int eMutex);
158+
static void async_cond_wait(int eCond, int eMutex);
159+
static void async_cond_signal(int eCond);
160+
static void async_sched_yield(void);
161+
162+
The functionality required of each of the above functions is described
163+
in comments in sqlite3async.c.
164+

0 commit comments

Comments
 (0)
0