> 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
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
