> I strongly recommend that you always make the child side of fork(2) > either exit(2) or exec(2) immediately.
Sorry Nico, I never saw this response -- I appreciate it! What do you mean, "immediately"? As I said, my child comes to life, does some work without touching (its copy of) existing SQLite strucures, and then calls exit(2). The lifetime of the child is small wrt the lifetime of the parent. Let's assume for the moment that I don't care about safety wrt non-sqlite libraries (except of course any libraries on which sqlite depends). > With respect to SQLite3, there are two sets of fork-safety issues: file > descriptor offsets (use USE_PREAD to avoid this issue), I take you to mean that the child and parent's fds point to the same underlying file description, and if the child changes the file description then it will have a side effect in the parent. But I have assumed that the child does not make any sqlite api calls against existing sqlite structures. I believe this assumption allows me to conclude that sqlite will not touch any existing fd, and hence will not bear such an impact on the parent (even if the child makes sqlite api calls against structures the child creates on its own). Am I right? > and POSIX file byte range locks. I'm not using POSIX locks, so I'm good to go there. But even if I were, I believe my above reasoning applies equally well here, since I believe your reason for being concerned about it is similar. The fds that were duplicated across the fork refer to the same underlying file description, so we are technically in a "dangerous" state: the child *could*, at its whim, release the parent's lock (for example). But if it guarantees not to do so (by guaranteeing to make no sqlite calls against existing structures), then no harm will result. Thanks, Eric -- Eric A. Smith Impartial, adj.: Unable to perceive any promise of personal advantage from espousing either side of a controversy or adopting either of two conflicting opinions. -- Ambrose Bierce, "The Devil's Dictionary" _______________________________________________ sqlite-users mailing list email@example.com http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users