2. disable asserts. I don't know how this is done in C, but I assume
that in
a release build, asserts are off.
Disable asserts() using -DNDEBUG=1. This more than doubles the speed
of SQLite. Asserts() are turned off in release builds.
We build sqlite3.08 as follows: ./configure --disable-shared
mike cariotoglou wrote:
2. disable asserts. I don't know how this is done in C, but I assume that in
a release build, asserts are off.
Disable asserts() using -DNDEBUG=1. This more than doubles the speed
of SQLite. Asserts() are turned off in release builds.
--
D. Richard Hipp -- [EMAIL PROTECTED
Correction: I misread the code in os_unix.c. There is NO simplistic mutex
mechanism, just the pthread_mutex_lock call.
So, the only way for your code to fail because of this would be to
1. compile without THREADSAFE
And
2. disable asserts. I don't know how this is done in C, but I assume that in
(unless the default,
simplistic mutex mechanism in sqlite3OsEnterMutex counts as a bug)
-Original Message-
From: Eli Burke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 12, 2005 6:34 PM
To: sqlite-users@sqlite.org
Subject: [sqlite] multiple thread concurrency problem with exclusive
I hate to beat on a tired horse (threads and db locking issues), but I
am running into what I believe is a bug as we scale up the number of
threads in our application. A little background: there is a main
scheduler thread that does most of the processing, and client threads to
handle remote con
5 matches
Mail list logo
