beagle should just be using the main sqlite package instead of the old and
obsolete sqlite2 version. Otherwise, we're back to the old berkeley db 1.85 ->
The explanation at
just makes me feel even more queasy -- things are just as likely to hit problems
with those sorts of threaded accesses in sqlite2; it just doesn't keep you from
shooting yourself in the foot like sqlite3 does.
Also, http://www.sqlite.org/cvstrac/wiki?p=MultiThreading makes it seem like
things should be safe as long as you're careful.
See bug #166319 about thread safety for sqlite package (i.e. sqlite3). This is
currently not enabled, but it should be.
As far as I can see, sqlite2 package also isn't built to be thread safe.
In relation to comment #1, it seems that the situation that beagle is hitting
(different threads using the same connection structure) is only solved in the
3.3.1 alpha version of SQLite, and not yet in the stable version 3.2.8.
Does anyone here if know if the supposed bugs in Red Hat Linux 9 the page keeps
harping about are still in recent Fedoras? I certainly hope not. If
threadsOverrideEachOthersLocks variable in os_unix.c is related, then it would
seem that this is not a problem any more, because in Rawhide it gets set to 1.
Maybe the real solution here is to bite the bullet and go 3.3.1?
bojan: there is no --enable-threadsafe in sqlite2 configure.
I know. I think you need to do -DTHREADSAFE=1 or some such.
I'm building the sqlite2 package with THREADSAFE defined now.
Beagle 0.2.1 released today, from the announcement
"CHANGES SINCE 0.2.0
Reenable Sqlite 3 support, but only if you have 3.3.1 or newer. (Joe)"
I'm presuming 0.2.1 will get sucked into rawhide for FC5T3?
Stable version 3.3.3 is out now. So, beagle can link itself to that, once it
gets delivered to Rawhide.