Hello. I'm wondering if CONFIG_SERIALIZED is a superset of CONFIG_MULITHREAD, recursive mutex wise.
I imagine MULTITHREAD is turning on mutexes to protect the pager and other "low-level" execution stuff, and SERIALIZED is turning on more mutexes to protect stuff hanging off the connection, like the parser and vdbe code generator. The reason I ask is that I had this great system where I was running MULTITHREAD and was giving each thread its own handle via a "handle cache" that examined characteristics of the current thread to decide which handle to hand out when a open was requested. However, with the rise of Grand Central Dispatch and anonymous block execution on iOS and OS X, the threading model has become a complete circus and also, certain calls I have used in the past to do my cache magic have been deprecated -- the result is that the cache is getting fooled and passing the same connection handle to more than one thread (on rare occasions) and BOOM! So...the easiest fix is to just switch to SERIALIZED. But I want to be sure I can still (mostly) have separate connections for each thread, but *occasionally* have more than one thread on the same connection. That is, I am assuming is not a requirement of SERIALIZED that ALL threads come banging in on a same global connection. (I mean, I've already thrown the switch and it seems to work, but thought I'd also ask to see if I'm missing anything.) Someday, of course, I'll rework the handle cache...."when I have time" (yeah, right). -- Ward _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
