Well, for my part, I forgot that I'm not including the R-tree stuff at this
point. I do include FTS (that's why I have a custom build, not to mention the
latest WAL stuff.)
And to the extent it matters, I'm not using LLVM.
But I am building -O0 -ggdb. That doesn't do any inline or deadcode
> Compiling a static library of SQLite's amalgamated version weighs at about
> 4.3 MB
Where are you coming up with this number? My .a is 2792KB and that's with both
armv6 and armv7, debugging, and full symbols.
I pull in sqlite3, openssl, about a billion other things, and plenty of my own
> But apparently your "not 100% sure" is actually "it's not
> true" in this case (as your tests showed).
No, I think we're good. As long as one is very careful (as Roger mentioned),
it seems to work fine under GCD. I was kinda reaching, thinking that moving
across threads mattered.
I was
Ah, crud. I kinda forgot I had a WAL checkpoint thread running. I thought I had
disabled that a long time ago. And it was sharing a connection on a different
thread.
Fixing that, things seem stable under GCD with SQLITE_OPEN_NOMUTEX.
I'm still not 100% sure if there's a problem sharing
> Isn't that exactly what NOMUTEX does?
The docs (http://www.sqlite.org/threadsafe.html) say
The SQLITE_OPEN_NOMUTEX flag causes the database connection to be in the
multi-thread mode and
the SQLITE_OPEN_FULLMUTEX flag causes the connection to be in serialized mode.
Is this wrong?
>> I've been using sqlite3 under iOS fine in FULLMUTEX mode, but it dies
>> horribly with NOMUTEX
>
> What problem are you trying to solve by getting rid of SQLite's mutexes?
> Even if you remove them you still have to add the same thing back in again
> to ensure you don't use SQLite internals
This is a little out there but I've been thinking about it and wondered if
anyone had any comments:
I've been using sqlite3 under iOS fine in FULLMUTEX mode, but it dies horribly
with NOMUTEX and I'm pretty sure this is because of my use of Grand Central
Dispatch (GCD).
GCD is related to
> Upgrading zlib to the latest release (1.2.5) fixed all of my valgrind
> warnings
Thanks. I'll try to replicate ...
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> Please try the latest code checkin (
> http://www.sqlite.org/src/info/e569f18b98) and let me know if it works any
> better for you.
Thanks. I've already adjusted the code to manually assign keys, but I'll try to
get back to checking it.
___
> I have not yet figured out why valgrind warns on linux-64 but not on
> linux-32 and whether or not this is anything to be concerned about.
Thanks for letting me know. This is x86_64 for me as well, though on OS X.
___
sqlite-users mailing list
I'm getting conditional branch warnings from valgrind that all percolate up via
a WAL path. Anybody know if these are known & benign?
This is, admittedly, off a sqlcipher-patched version of 3.7.6.2. I don't think
that should relate but I'll check if they shouldn't be occurring.
I gather sqlite3_last_insert_rowid doesn't play well with FTS? I don't see an
exception noted in the docs but neither are there non-manually managed examples.
I'd prefer not to manually mange them but ...
___
sqlite-users mailing list
12 matches
Mail list logo
