On May 10, 2016, at 4:15 PM, Richard Hipp <drh at sqlite.org> wrote:
> On Tue, 10 May 2016 22:47 +0100, Tim Streater <tim at clothears.org.uk> wrote: >> >> I read it as two different *copies*. It doesn't sound to me as if the >> versions have anything to do with it. >> > > Correct. Two different *copies*of the library. They can both have > the same version number - that doesn't matter. > ? Oh that actually makes more sense?but also even more concerning in a way, unless I?m still misunderstanding the conundrum. Typically concurrency happens when two different users execute their program that has sqlite compiled into it;?.. concurrently. Is this problem unique to some library I am not aware about or would it effect any two people trying to use the sqlite3 binary at the same time (each one calling their own instance of it)?or say?calling fossil at the same time, for example? Each user instance starts a process running, with its own globals?and they could each try to hit a certain sqlite DB concurrently?from different processes? But I thought this was supposed to be the whole point of sqlite?that it can handle that?it just may force one or the other of them to wait until the file is unlocked.. So I was under the impression that sqlite lite was safe, but slow, for concurrent attempts to write to a DB file. But it sounds like you?re saying its not safe?though its still not entirely clear to me if I am understanding the problem right or how to avoid it.
