Re: esql open db ;vfork
Posted in 1996
}From: aem@cyberhighway.net (Arthur Mills) }Date: 23 Jul 1996 23:47:21 GMT }X-Informix-List-Id: <news.26471> } }I was wondering if I could do something like the following } }open db }while 1 }{ }check time/date }format query for table of date }if request from unix port }then }fork and preform the data I was pased }} } }can I open and format my sql command before I fork or do I need to }fork then do the open and format You can format the command at any stage you like -- you can manipulate the string in whatever way gets you the right answer. However, you aren't free to open the database like that -- if a child process is to access the database, then it should initiate the connection. Anything else is unreliable, and unsupported. So, the 'open db' part of your algorithm should be in the 'fork and preform the data I was pased' phase of the algorithm. }From: Mike Segel <mikey@segel.com> }Date: Wed, 24 Jul 1996 04:53:30 +0000 }X-Informix-List-Id: <news.26485> } }You can do it either way. If my memory of C / Unix is still ok, }the fork() call will copy the memory segment of the parent to }the child, so that all variables should be copied and *active*. } }I guess it all depends on what you want to do. There are additional problem if, as the subject line suggests, you use vfork() in place of fork(). If you do a vfork(), then the child goes scribbling on the parent process's data pages. If it returns from a function, or does pretty much anything except exec() a new program, you are liable to immense problems (aka core dumps, etc). Unless you are really confident that (1) you need the minor performance gain from using vfork() in place of fork() and (2) you won't ever need to port to an environment which doesn't support vfork() and (3) your coding really meets the requirements of vfork() (which I think it does not do) -- unless you meet all three criteria, you should use fork(), and the child code should open the database and perform whatever work is required. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>