Ok?starting to sound safer. :-)
at a minimum this problem only occurs when multi-threading is being used to
access a sqlite DB file. but I think its probably even more specific then that?
When you say ?two copies of sqlite in the same address space?, this is the part
I am getting confused about I guess. I guess you mean the single-file sqlite
dot c file is compiled into a single executable more then once, somehow
avoiding namespace conflicts.
In such a case, then each of those code-instances would have what it thinks is
a global to keep track of the db file lock, but in actuality they are each
using their own private global.
Do I understand it correctly now?
On May 11, 2016, at 8:36 AM, Richard Hipp <drh at sqlite.org> wrote:
> On 5/11/16, Steve Schow <steve at bstage.com> wrote:
>>
>> Typically concurrency happens when two different users execute their program
>> that has sqlite compiled into it;?.. concurrently.
>
> The problem only comes up with two different copies of SQLite are
> running within the same process. The same program being run twice is
> fine.
>
> The problem is a bug in the posix APIs for file locking. I say "bug".
> It is not an implementation problem. The implementation is correct on
> all major unix systems. The problem is in the *design*.
>
> In posix, suppose you open a file "xyzzy" and take a lock on that file
> using the file descriptor returned by open(). That works fine.
>
> But then if another thread in the same process (technically: another
> thread with the same result from getpid()) does this:
>
> close(open("xyzzy"))
>
> The close() operation cancels all locks held on the "xyzzy" file, even
> locks created by different threads using different file descriptors.
>
> This is crazy. Everybody acknowledges that it is crazy. But it is the
> posix standard.
>
> In order to work around the problem, SQLite has to use global
> variables to track every close() operation and defer those that are
> against files with locks held by other file descriptors. But if you
> have two copies of SQLite in the same address space, they will use
> different global variables and may not know about each other, and
> hence locks can get cancelled.
> --
> D. Richard Hipp
> drh at sqlite.org
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
