On Thu, 16 Sep 2004 [EMAIL PROTECTED] wrote:
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.
??
do a man 2 fcntl and you'll see:
...
F_GETFD
Read the close-on-exec flag. If the FD_CLOEXEC bit is 0, the
file will remain open across exec, otherwise it will be closed.
...the close-on-exec bit has nothing to do with forking, only exec'ing. therefore daemon code would operate exactly as before. if fact the cose in question IS a daemon and i'm doing this manually using /proc - but it's not portable.
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.
sure. the problem is that, when a fork occurs, the sqlite api may have many files opens, not only the db handle, such as the db-journal file or /var/tmp/XXXX files and those files are not exposed to the api client. therfore they have no reliable way to know which OTHER files to close/keep-open. for example:
harp:~ > strace sqlite db 'create table t(f);begin;insert into t values (42);commit;' 2>&1| grep open | tail
open("/etc/passwd", O_RDONLY) = 3
open("/home/ahoward/.sqliterc", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/ahoward/db", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 3
open("/var/tmp/sqlite_ZRnHLHGmAfplF87", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 4
open("/home/ahoward/db-journal", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 5
open("/home/ahoward", O_RDONLY|O_LARGEFILE) = 6
open("/var/tmp/sqlite_ZRnHLHGmAfplF87-journal", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE,
0600) = 7
open("/var/tmp", O_RDONLY|O_LARGEFILE) = 8
open("/home/ahoward/db-journal", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 5
open("/home/ahoward", O_RDONLY|O_LARGEFILE) = 6so here we see that, if a child was created during a transaction it would need to close quite a few files other than the db itself - it would be nearly impossible for a client to know which ones to close before execing (not forking).
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.
that IS good advice ;-) i'll see if that does the trick. i'm only worried that closing the database in the child may do something like flush file handles or commit/abort the current transaction - that would be VERY bad if it occured in both parent and child.
kind regards.
-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it. | --Dogen
===============================================================================
