To get this effect you need to have 2 (shareable) images, each with their own and very private copy of sqlite, loaded into the same process.
With the mentioned #defines that make all sqlite3 symbols become static, it is quite easy to compile sometool.c and sqlite3.c into a single sometool.so (or .dll for windows) file that initializes sqlite's global variables. If I now compile myapp.c and sqlite3.c (same or different version does not matter) into myapp.so (again or .dll for windows), which initializes the global variabels visible to myapps' copy of sqlite. These are distinct from sometool's sqlite global variables. I may find sometool quite handy and decide to call it from within myapp code by dynamically linking to the shareable object/dll. This makes 2 copies of sqlite active in one process. This is probably not a problem, because sometool is presumably using sqlite to access ist own db files, of which myapp has no knowledge. But if myapp's function is to "explore" sqlite dbs it may stumble over sometools' db file and open a second filehande to it. Now and only now is there potential for corruption. -----Urspr?ngliche Nachricht----- Von: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-bounces at mailinglists.sqlite.org] Im Auftrag von Steve Schow Gesendet: Mittwoch, 11. Mai 2016 17:04 An: SQLite mailing list <sqlite-users at mailinglists.sqlite.org> Betreff: Re: [sqlite] 2 different SQLite versions inside the same process space 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 _______________________________________________ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___________________________________________ Gunter Hick Software Engineer Scientific Games International GmbH FN 157284 a, HG Wien Klitschgasse 2-4, A-1130 Vienna, Austria Tel: +43 1 80100 0 E-Mail: hick at scigames.at This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation.
