On Fri, 15 Nov 2019 at 16:10, Graham Holden <sql...@aldurslair.com> wrote:
> I've been having problems with my email system... I don't think > earlier attempts at sending have made it to the list, but if they > did, apologies for any duplication... > > Monday, November 11, 2019, 5:46:05 PM, Jukka Marin <jukka.ma...@jmp.fi> > wrote: > > >> On 11 Nov 2019, at 5:13pm, Jukka Marin <jukka.ma...@jmp.fi> wrote: > >> > >> > The main process first opens the databases and checks that their > >> > version matches that of the software and if not, the databases are > >> > closed and initialized by running a script. > >> > > >> > After closing the databases, main process forks the children and > >> > all processes (including main process) open the databases and use > >> > their own connections. > >> > > >> > What I was trying to ask was this: If any of the children dies > >> > (a bug in the code), main process will restart the child. At > >> > this point, the main process has the databases open, so the new > >> > child receives the connections as well. What should I do now? > >> > > This isn't from personal experience, but (possibly misremembered) > snippets from this list and (possibly incorrect) deductions from > them... > > The problem (or, perhaps, "a" problem) with passing SQLite connections > across fork() is, I think, how Linux?/POSIX? deals with file-locks on > the underlying file-handle. IIRC, if both parent/child process share a > file-handle, and one of them closes that file, then ALL file-level > locks (which is what SQLite uses) on that handle are released: not > just the ones created by the terminating process. > The mechanism you're thinking of exists, but only between threads of the same process. It's also described in the "how to corrupt an sqlite database file" writeup, section 2.2: https://sqlite.org/howtocorrupt.html#_posix_advisory_locks_canceled_by_a_separate_thread_doing_close_ fork creates separate processes, so it shouldn't be impacted by that mechanism. But there's an easily identified problem: posix locks are not inherited by a fork()ed child, and sqlite keeps track (in-memory) of what locks it has acquired. So after a fork() the child will inherit sqlite's internal idea of what locks are held, but none of the actual locks, making it instantly out of sync with reality if any locks were held. -Rowan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
