Re: [sqlite] Using SQLite with R*Tree and FTS3 support in iOS
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 elimination and it throws lots and lots and lots of symbol stuff in. Lots. Really. Lots. Unless I'm missing something, you're looking at something that doesn't matter. The size of the .a is very weakly correlated to resulting size of the executable. You don't ship the .a (or you certainly shouldn't be). It just gets linked into your executable and then you strip your executable. Both the linking and the stripping steps remove a ton of symbol information. Much of the size of the sqlite .o's and .a's are symbols that are going to be dumped. To give you an idea, as I said, my sqlite library is about 3M. My custom openssl build is 17M. My own library is 37M. The final executable in debugging mode is 7M before strip and 5M. Again, with -O0. I'm pretty sure this is a non-issue. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Using SQLite with R*Tree and FTS3 support in iOS
> 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 code and my post-strip size of the executable is still on the order of 5MB and that's still with debugging turned on. I may be missing something, but I can't believe this a real issue. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] threading and grand central dispatch (OS X/iOS)
> 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 being very careful right up to completely forgetting about a wal checkpoint thread which I haven't thought about in months. And which was using the same connection that "belongs" to another thread. Thanks for the comments, all. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] threading and grand central dispatch (OS X/iOS)
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 connections across threads with SQLITE_OPEN_NOMUTEX as long as I guarantee that they aren't concurrent. I suspect there aren't, but I'm not 100% sure. Any case where sqlite3 would be less than happy that pthread_self wasn't always the same? Note that this isn't me redoing what sqlite3 is doing: GCD provides a higher level abstraction that guarantees (modulo my stupidity) non-concurrency. It should be enough for SQLITE_OPEN_NOMUTEX while being (at least slightly) more concurrent than SQLITE_OPEN_FULLMUTEX. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] threading and grand central dispatch (OS X/iOS)
> 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? ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] threading and grand central dispatch (OS X/iOS)
>> 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 concurrently. Not trying to throw them away ... trying to switch from Serialized to Multi-thread. My reading of the docs says that that's what SQLITE_OPEN_NOMUTEX does. Did I misinterpret something? ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] threading and grand central dispatch (OS X/iOS)
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 threads but has some twists. In my simplified model, I create a small number of GCD queues and those are essentially one-to-one to threads. Each queue has its own db connection and they aren't shared. But there's one twist, which is the ability in GCD to make a synchronous call from one queue/thread to another. So code executing on queue A in thread A can make a synchronous call to queue B. GCD will make sure that queue B (and queue B's thread) is inactive. And my code will make sure that for the duration of this call, I'm using queue B's db connection. But it's "borrowing" queue A's thread. So if sqlite3 does a pthread_self() during this call, it's going to get A's threadid, not B's. My guess is this confuses it. So if I wanted to "fix" this, somehow I'd provide a GCD thread provider that was essentially posix threads but returns GCDs queue id instead of the pthreadid. Comments? Anybody looked at this? ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] valgrind & WAL w/3.7.6.2
> 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
Re: [sqlite] FTS & sqlite3_last_insert_rowid
> 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. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] valgrind & WAL w/3.7.6.2
> 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 sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] valgrind & WAL w/3.7.6.2
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. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] FTS & sqlite3_last_insert_rowid
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 sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
