"Ara.T.Howard" <[EMAIL PROTECTED]> writes: > the problem is that the child inherits all the open fds from the 'begin > transaction' (sqlite db-journal, etc.). in my case, the child never uses > these at all. regardless, when the parent does the unlink the sillyname is > created. > > the child could attempt to close this fd, but it's difficult for the child > to determine which files to close. i think a better solution would be for > the sqlite api to set the close-on-exec bit of any files created during a > transaction - that way a fork/exec will not inherit all those open files. > in fact - it seem as if setting the close-on-exec bit on ALL files the > sqlite api opens is the right thing to do since you'd never want them open > after an exec right?
If this were implemented, it would remove the capability to go into the background. A common thing for a daemon process to do upon start-up is to get everything initialized (e.g. open databases and do other things that could fail and would need to be reported to the user), and then fork() and the parent process exits, leaving the child running. There's nothing wrong with *either* the parent process continuing to use an open database handle _or_ the child process continuing to use an open database handle. It just can't be used by both, and should be closed by the one not using it. Note that if your child does not need the sqlite database handle, it should call sqlite_close() to release of all resources associated with that handle (not just close the file). That should solve your problem. Derrell
