Large operations in sync databases
asutherland at asutherland.org
Tue Jul 13 14:31:28 UTC 2010
On 07/13/2010 05:11 AM, Ben Bucksch wrote:
> I take it sqlite is not multi-threaded? If it was, it should take care
> of the problem. If it isn't, I am not sure two databases solve the
> problem, as sqlite may still block even across databases. Have you
> tried both variants?
The greater context is that rkent is implementing a new account type
targeted at Thunderbird 3.1. The need for anything to be synchronous is
an outgrowth of the semantics of most Thunderbird message database
operations executing synchronously on the main thread. The choice of
multiple databases is to eliminate the chance for a long-running
operation off the main thread to acquire a lock that would block the
main thread. Also, to keep all database operations on the main thread
predictably short so that even when disk seeks happen, there are few
enough that interactive response is not greatly impacted.
To more explicitly answer the quoted section, SQLite has various
mechanisms of support for multiple threads to access a single database,
but the best-case situation finds locks operating on a table level of
granularity, which, once acquired, are retained for the duration of the
transaction. ( http://www.sqlite.org/sharedcache.html). There some
other ways one can roll, but they also have similar worst-case behaviour.
Obviously, in the long run we want all Thunderbird activity (both core
and extension-provided account types) to have all their I/O happen off
the main thread and without storing everything in memory.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning