<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 07/13/2010 05:11 AM, Ben Bucksch wrote:
<blockquote cite="mid:4C3C2DB4.9090105@beonex.com" type="cite">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?
<br>
</blockquote>
<br>
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.<br>
<br>
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. (
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="http://www.sqlite.org/sharedcache.html">http://www.sqlite.org/sharedcache.html</a>).
There some other ways one can roll, but they also have similar
worst-case behaviour.<br>
<br>
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.<br>
<br>
Andrew<br>
</body>
</html>