On Fri, Jul 09, 2010 at 04:52:35PM -0400, Eric Smith wrote: > > > 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"?
Good question. One answer: "before ever utilizing state inherited from the parent for libraries such as libsqlite3". A much more conservative answer: "the exit(2) or exec(2) call should be lexically close to the fork(2) call, and it should be obvious from lexical context that the child will not ever utilize state inherited from the parent for libraries such as libsqlite3". (What a mouthful. If there's a good English-language word to describe the above without superfluously referring to 'time', as 'immediately' does, I'd love to hear what it is.) > 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. That's fine. The child could run forever then. Of course, if you design an architecture like that you end up creating the temptation (for subsequent developers) to do more in the child process later, so I'd not recommend it. > 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). Good luck! :) > > 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. Exactly. > 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? Correct. > > 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. No, I meant that if you stepped, in the child, a statement inherited from the parent then the child would go ahead believing it has a lock when in fact it does not (because the parent got the lock). Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
