> 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.


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

Reply via email to