> In our tests, the overhead of mutexing is not negligible. It slows
> down the
> database by about 8%. Nevertheless, we recognize that many people want
> to run multiple threads (despite my heartfelt pleas to abstain from
> that dreadful
> practice) so we probably will make the prebuilt
On Sep 2, 2007, at 10:18 AM, Christian Smith wrote:
Is it not worth simply making the library threadsafe by default?
There is basically no platform supported today that doesn't have
some form of thread abstraction, the overhead of mutex locking is
probably negligible,
See ticket
[EMAIL PROTECTED] uttered:
[EMAIL PROTECTED] wrote:
Ken <[EMAIL PROTECTED]> wrote:
Recompiled with:
gcc -DSQLITE_THREADSAFE -I. -I../src
^^^
Should be -DSQLITE_THREADSAFE=1
The =1 is important in this case.
This problem will likely come up again. To try and work
I did do an update this morning to pick up the latest code base.
I guess the prior version that I had check out earlier in the week was not the
most current.
[EMAIL PROTECTED] wrote: Ken wrote:
> The segv seems to be resolved. At least no more issues
> with this version of the code.
>
--- Dan Kennedy <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-30 at 19:13 -0700, Joe Wilson wrote:
> > I see what's going on now. I incorrectly assumed that both configure
> > builds and the amalgamation were both threadsafe by default in the
> > 3.4.x sources.
> >
> > It appears that a default
Ken <[EMAIL PROTECTED]> wrote:
> The segv seems to be resolved. At least no more issues
> with this version of the code.
>
That's funny, because I haven't changed anything to
address your problem. I never could reproduce it.
Perhaps you were using a version of the code that was
two or three
The segv seems to be resolved. At least no more issues with this version of the
code.
$Id: sqliteInt.h,v 1.606 2007/08/30 14:10:30 drh Exp $
Thanks for a great product.
Ken
On Thu, 2007-08-30 at 19:13 -0700, Joe Wilson wrote:
> > > > latest CVS:
> > > >
> > > > #if SQLITE_THREADSAFE
> > > > # include
> > > > # define SQLITE_UNIX_THREADS 1
> > > > #endif
> > > >
> > >
> > > I don't know where you are seeing this. The latest is
> > >
> > >
> > >
> > > latest CVS:
> > >
> > > #if SQLITE_THREADSAFE
> > > # include
> > > # define SQLITE_UNIX_THREADS 1
> > > #endif
> > >
> >
> > I don't know where you are seeing this. The latest is
> >
> >
> > http://www.sqlite.org/cvstrac/filediff?f=sqlite/src/sqliteInt.h=1.592=1.593
>
> Look in
--- [EMAIL PROTECTED] wrote:
> This problem will likely come up again. To try and work
> around it, I have added a new (experimental) API to the
> latest version in CVS. Call
>
> sqlite3_threadsafe()
>
> To get back a boolean to indicate whether or not your
> build is threadsafe.
Could
--- [EMAIL PROTECTED] wrote:
> Ken <[EMAIL PROTECTED]> wrote:
> > Recompiled with:
> > gcc -DSQLITE_THREADSAFE -I. -I../src
> ^^^
>
> Should be -DSQLITE_THREADSAFE=1
>
> The =1 is important in this case.
-DSQLITE_THREADSAFE is equivalent to -DSQLITE_THREADSAFE=1
$ cat
[EMAIL PROTECTED] wrote:
> Ken <[EMAIL PROTECTED]> wrote:
> > Recompiled with:
> > gcc -DSQLITE_THREADSAFE -I. -I../src
> ^^^
>
> Should be -DSQLITE_THREADSAFE=1
>
> The =1 is important in this case.
>
This problem will likely come up again. To try and work
around it,
Ken <[EMAIL PROTECTED]> wrote:
> Recompiled with:
> gcc -DSQLITE_THREADSAFE -I. -I../src
^^^
Should be -DSQLITE_THREADSAFE=1
The =1 is important in this case.
--
D. Richard Hipp <[EMAIL PROTECTED]>
And the sqliteInt.h file is id as:
** @(#) $Id: sqliteInt.h,v 1.605 2007/08/29 12:31:28 danielk1977 Exp $
Let me know if you need anything else..
Thanks,
Ken
[EMAIL PROTECTED] wrote: Joe Wilson wrote:
>
> latest CVS:
>
> #if SQLITE_THREADSAFE
> # include
> # define SQLITE_UNIX_THREADS 1
Recompiled with:
gcc -DSQLITE_THREADSAFE -I. -I../src -DSQLITE_DEBUG=1 -DTHREADSAFE=1
-DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1
-DHAVE_READLINE=1
Ran code (hardware is a dual core x86_64 amd cpu).
sqlitetest_thrd35: ../src/btree.c:1816: sqlite3BtreeBeginTrans:
** $Id: btree.c,v 1.420 2007/08/30 01:19:59 drh Exp $
Compilation:
../configure --enable-threadsafe --disable-tcl --enable-tempstore
make
gcc -g -O2 -I. -I../src -DNDEBUG -DTHREADSAFE=1
-DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -c
../src/alter.c -o alter.o >/dev/null
--- [EMAIL PROTECTED] wrote:
> Amazingly enough, the test program works OK most of
> the time even with mutexes all disabled. But every
> now and then I get the segfault.
>
> It's a weak thread-test that works OK must of the
> time with mutexes disabled. :-) Or perhaps it is
> a very robust
--- [EMAIL PROTECTED] wrote:
> Joe Wilson <[EMAIL PROTECTED]> wrote:
> >
> > latest CVS:
> >
> > #if SQLITE_THREADSAFE
> > # include
> > # define SQLITE_UNIX_THREADS 1
> > #endif
> >
>
> I don't know where you are seeing this. The latest is
>
>
>
Joe Wilson <[EMAIL PROTECTED]> wrote:
>
> latest CVS:
>
> #if SQLITE_THREADSAFE
> # include
> # define SQLITE_UNIX_THREADS 1
> #endif
>
I don't know where you are seeing this. The latest is
http://www.sqlite.org/cvstrac/filediff?f=sqlite/src/sqliteInt.h=1.592=1.593
--
D. Richard Hipp
--- Joe Wilson <[EMAIL PROTECTED]> wrote:
> I thought there was a checkin a few months ago that made sqlite3
> threadsafe by default.
>
> os_unix.c
> revision 1.128
> date: 2007/04/01 18:46:19; author: drh; state: Exp; lines: +4 -1
> Make unix builds threadsafe by default.
>
> I
--- Dan Kennedy <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-30 at 10:13 -0700, Joe Wilson wrote:
> > Compiled without -DSQLITE_DEBUG=1 which presumably changes the timing.
> >
> > cvs up -A
> > make distclean
> > # thrd35.c = http://marc.info/?l=sqlite-users=118848741522192=2
> > cp thrd35.c
Joe Wilson <[EMAIL PROTECTED]> wrote:
> Compiled without -DSQLITE_DEBUG=1 which presumably changes the timing.
>
> cvs up -A
> make distclean
> # thrd35.c = http://marc.info/?l=sqlite-users=118848741522192=2
> cp thrd35.c src/shell.c
> ../configure --disable-shared && make LIBPTHREAD=-lpthread
On Thu, 2007-08-30 at 10:13 -0700, Joe Wilson wrote:
> Compiled without -DSQLITE_DEBUG=1 which presumably changes the timing.
>
> cvs up -A
> make distclean
> # thrd35.c = http://marc.info/?l=sqlite-users=118848741522192=2
> cp thrd35.c src/shell.c
> ./configure --disable-shared && make
Compiled without -DSQLITE_DEBUG=1 which presumably changes the timing.
cvs up -A
make distclean
# thrd35.c = http://marc.info/?l=sqlite-users=118848741522192=2
cp thrd35.c src/shell.c
./configure --disable-shared && make LIBPTHREAD=-lpthread sqlite3
./sqlite3
valgrind -v ./sqlite3 2>&1 | tee
Joe Wilson <[EMAIL PROTECTED]> wrote:
> I also see random crashes with sources from CVS as of
> Thu Aug 30 12:20:43 EDT 2007 using Ken's program below.
>
> http://marc.info/?l=sqlite-users=118848741522192=2
>
> It's timing dependent.
> On a single core Pentium4 machine it crashes once in 10
Another unique valgrind stack trace.
http://marc.info/?l=sqlite-users=118848741522192=2
==14918== Thread 2:
==14918== Invalid read of size 4
==14918==at 0x80534F9: sqlite3OsWrite (os.c:38)
==14918==by 0x8056C06: syncJournal (pager.c:2765)
==14918==by 0x80581A8:
Also:
==14673== Invalid read of size 4
==14673==at 0x80534F9: sqlite3OsWrite (os.c:38)
==14673==by 0x8050A17: sqlite3BtreeBeginTrans (btree.c:1850)
==14673==by 0x807E068: sqlite3VdbeExec (vdbe.c:2519)
==14673==by 0x805C209: sqlite3_step (vdbeapi.c:328)
==14673==by 0x8060951:
I also see random crashes with sources from CVS as of
Thu Aug 30 12:20:43 EDT 2007 using Ken's program below.
http://marc.info/?l=sqlite-users=118848741522192=2
It's timing dependent.
On a single core Pentium4 machine it crashes once in 10 runs.
Sometimes it produces this valgrind error:
Ken <[EMAIL PROTECTED]> wrote:
> program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1080043872 (LWP 15448)]
> moveToChild (pCur=0x569058, newPgno=) at btree.c:3304
> (gdb)
>
>
> if( rc ) return rc;
> pNewPage->idxParent = pCur->idx;
> pOldPage = pCur->pPage;
>
Dan Source code is attached. I didn't write this, someone else from the forum
did their name is not on it, nor coppyrighted.. I thought it was a clean way to
test threading.
Interestingly if you remove out the shared cache everything runs to completion.
Dan Kennedy <[EMAIL PROTECTED]> wrote:
Hi Ken,
Probably a bug in the new threading stuff. Can you share
source code for this test or is it part of some large app?
Either way, thanks for the report.
Dan.
On Wed, 2007-08-29 at 22:15 -0700, Ken wrote:
> Also erros out here, sporadically.
> int sqlite3OsWrite(sqlite3_file *id, const
Also erros out here, sporadically.
int sqlite3OsWrite(sqlite3_file *id, const void *pBuf, int amt, i64 offset){
return id->pMethods->xWrite(id, pBuf, amt, offset);
}
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1075841376 (LWP 15747)]
0x0040c413 in
4 threads, shared_Cache enabled
LOOP 100
BEGIN
LOOP 50 times
INSERT
end LOOP
COMMIT
SELECT COUNT(*) ...
end LOOP
program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1080043872 (LWP 15448)]
moveToChild (pCur=0x569058, newPgno=) at
program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1080043872 (LWP 15448)]
moveToChild (pCur=0x569058, newPgno=) at btree.c:3304
(gdb)
if( rc ) return rc;
pNewPage->idxParent = pCur->idx;
pOldPage = pCur->pPage;
pOldPage->idxShift = 0; < Error
34 matches
Mail list logo
