> Le 11 juil. 2016 à 21:57, Brian Vincent <bra...@gmail.com> a écrit : > > Yes, you seem to understand the issue. The issue only happens when using > shared caches. > > I've reproduced the issue using both SERIALIZED and MULTITHREADED modes. > ... > Being an inherit limitation would seem to imply that there is no solution > to this problem, that having shared caches and WAL indexes rebuilding > necessarily should block all unrelated databases opening. I don't see why > that should be the case and I'll explain some reasons why. It's a little > bit hard for me to talk about it though, because I'm not entirely sure what > the lock SQLITE_MUTEX_STATIC_OPEN is protecting. When iterating through > the list of shared caches, it acquires the lock SQLITE_MUTEX_STATIC_MASTER, > so the other OPEN lock must be for something else. The comments say it's > to prevent a race condition and references "Ticket #3537", but I can't seem > to find that ticket.
Indeed: > sqlite3_mutex *mutexOpen = 0; /* Prevents a race condition. Ticket #3537 */ I couldn't find that ticket either. > Please let me know if I'm thinking about this problem clearly, or if you > would like me to test some things or write a simple test case. As I'm just as you a user of Sqlite, it probably is best to let its developers take on this thread from here (or from the beginning). -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
