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. What I *think* this may mean is that re-spawned children will inhereit the open file-handle of the SQLite connection opened by the parent after it initially fired all child processes. Even if the (re-spawned) child never make use of that connection or the file-handle, when it next dies (either a natural death or another unexpected termination), then the OS will close the inherited file-handle and release all file-locks on it (that would have been created by the parent process). At this point, the parent process will THINK it has appropriate file-locks and that it is safe to access the database file, but to all the other (child) processes, it does not appear to have any locks, and they too may try to access the database file. And that way, madness lies! I *suspect* Simon's "The conservative way to do it" (close the connection/file-handle around re-spawns) may be more necessary than originally thought. (Alternatively, perhaps, have whatever database access the parent is doing happen in another child process, and have the parent "just" monitoring processes and re-spawning as needed). Of course, I may be wrong, or the "releasing all locks" may only apply in some circumstances... hopefully someone with more direct experience can confirm or deny. Graham _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
