On Thu, Dec 16, 2010 at 09:41:27AM +0200, Yoni Londner wrote:
>
> > The underlying error here is that you are attempting to use threads in the
> > first place. You should never do that. Threads are evil and should be
> > avoided wherever possible. Use separate processes for concurrency.
> The underlying error here is that you are attempting to use threads in the
> first place. You should never do that. Threads are evil and should be
> avoided wherever possible. Use separate processes for concurrency. Threads
> in application programs always result in subtle bugs (such as
That's was fast!
I tried it, and it seems to work correctly now.
Thanks! :-)
Yoni.
On 16/12/2010 4:08 AM, Richard Hipp wrote:
> The patch at http://www.sqlite.org/src/ci/cf86affcb7 should fix this
> problem.
___
sqlite-users mailing list
The patch at http://www.sqlite.org/src/ci/cf86affcb7 should fix this
problem.
--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
On Wed, Dec 15, 2010 at 6:18 PM, Yoni Londner wrote:
> Hi Richard,
>
> >
> > Perhaps I speak too soon. I'm still getting the error even after
> changing
> > this to SQLITE_CONFIG_SERIALIZED. I am continuing to investigate
> >
>
> Note that I used two sql connections
Hi Richard,
>
> Perhaps I speak too soon. I'm still getting the error even after
changing
> this to SQLITE_CONFIG_SERIALIZED. I am continuing to investigate
>
Note that I used two sql connections (one for each thread)
Yoni.
___
sqlite-users
On Wed, Dec 15, 2010 at 11:14 PM, Doug wrote:
> . And getting concurrency with processes means you introduce the
> complexities of interprocess communication/synchronization which is much
> easier to handle with threads in the same process.
>
>
Doug, nothing stops you from
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Richard Hipp
>The underlying error here is that you are attempting to use threads in the
first place. You should never do that. Threads are evil and should be
avoided wherever possible. Use separate
On Wed, Dec 15, 2010 at 11:49 AM, Richard Hipp wrote:
>
>
> On Wed, Dec 15, 2010 at 8:34 AM, Yoni Londner wrote:
>
>> Hi,
>>
>> I wrote a little program that insert in a loop rows in to the DB, and in
>> another thread run wal_checkpoint.
>> After few
On Wed, Dec 15, 2010 at 8:34 AM, Yoni Londner wrote:
> Hi,
>
> I wrote a little program that insert in a loop rows in to the DB, and in
> another thread run wal_checkpoint.
> After few minutes (6-7) I get (consistently) the following assert error:
>
> sqlite_test:
Isn't that the default?
from sqliteInt.h:
#if !defined(SQLITE_THREADSAFE)
#if defined(THREADSAFE)
# define SQLITE_THREADSAFE THREADSAFE
#else
# define SQLITE_THREADSAFE 1 /* IMP: R-07272-22309 */
#endif
#endif
Anyway, I added the define and it still happening.
Yoni.
On 15/12/2010 3:39 PM, Marco
Try to add:
-DSQLITE_THREADSAFE =1
to your compilation options.
--
Marco Bambini
http://www.sqlabs.com
On Dec 15, 2010, at 2:34 PM, Yoni Londner wrote:
> Hi,
>
> I wrote a little program that insert in a loop rows in to the DB, and in
> another thread run wal_checkpoint.
> After few
Hi,
I wrote a little program that insert in a loop rows in to the DB, and in
another thread run wal_checkpoint.
After few minutes (6-7) I get (consistently) the following assert error:
sqlite_test: ..//src/wal.c:1364: walMerge: Assertion `iLeft>=nLeft ||
aContent[aLeft[iLeft]]>dbpage' failed.
13 matches
Mail list logo