Bug#326648: libsqlite3-0: database handles can't be shared among threads any more
[debian-devel CCed because I'm asking for advice at the end.]
Until sqlite 3.2.2, a database handle could be opened in one thread
and used in another. In 3.2.5 this has been disabled, and upstream
recommends to open a db handle for each handle; which has generated a
bit of traffic in the mailing list:
The reason for this change is that it didn't properly work on some
Linux systems. See these messages from the sqlite author:
My amarok package uses this feature (sharing db handles accross
threads), and with the recent upload of sqlite3, its sqlite-based
collection support no longer works (#326562, #312386). What is worse,
when talking with upstream about it, they tell me that hey have no
plans on changing their source code -- as they ship an internal copy
of sqlite, they'll re-enable the feature there instead.
If sqlite upstream fails to provide a solution for this, I fear I will
have to use the internal copy of sqlite that amarok provides (*).
Unless the solution is provided by the Debian package instead; but
this would be diverging from upstream, and I don't think it's a really
good idea unless we can know for sure we don't belong to the "does
sometimes not work" category outlined by D. Richard Hipp. Anybody has
an opinion on this?
(*) I'd be very unhappy with this, but I can't go on with "install
libsqlite3-0 3.2.2-3 and put it on hold" forever.
Also, I have no idea what's the case for Debian: "On some versions of
Linux, a thread is not able to override locks created by a different
thread in the same process." Does this depend on the kernel, on libc,
or on something else?
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Faced with the choice between changing one's mind and proving that there
is no need to do so, almost everyone gets busy with the proof.
-- J.K. Galbraith