maura@pyrltd.UUCP (Maura Clark) (06/23/89)
I am posting this on behalf of a customer of mine who has no net access. He has written a user exit which is called from an iap form. This exit in turn forks and execs another process (for print spooling or some such like activity). The problem is he cannot exit the form (gracefully) as long as this process is still alive. Anyone out there got any bright ideas why this happens and possible ways around it ? Thanks in advance ... Maura. -- * Maura Clark "A woman's work is never delegated !" * * Pyramid Technology UK Ltd Basil Fawlty * * Tel: +44 252 373035 * * Fax: +44 252 373135 ..ukc!pyrltd!maura *
Bron@cup.portal.com (George Bron Faison) (07/03/89)
Does your client spawn the process to run in the background? It appears that Sql*Forms (or IAP) doesn't want to terminate with the "child" process still active. I am assuming that the user exit in question returns to the form and returns SUCCESS, and then your user can't exit normally using the exit key? Is this correct? Is you client using the "system" call to spawn the child? Is using "host" an alternative?
sewilco@datapg.MN.ORG (Scot E Wilcoxon) (07/05/89)
In article <20077@cup.portal.com> Bron@cup.portal.com (George Bron Faison) writes: >It appears that Sql*Forms (or IAP) doesn't want to terminate with the >"child" process still active. I am assuming that the user exit I'm having similar problems with PRO*C (ORACLE's product, not "PRO-C") code. ORACLE uses SIGCLD and SIGTERM for its own purposes. I've had to disconnect from ORACLE in order to use child processes and I've seen ORACLE get stuck until all children terminated. These certainly are nuisances on UNIX where child processes are useful and in some cases necessary. The two manual pages which I found on signals contain inadequate information and the code sample is illiterate (it certainly can't compile). -- Scot E. Wilcoxon sewilco@DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress UNIX masts & rigging +1 612-825-2607 uunet!datapg!sewilco I'm just reversing entropy while waiting for the Big Crunch.
leo@philmds.UUCP (Leo de Wit) (07/06/89)
In article <10915@datapg.MN.ORG> sewilco@datapg.MN.ORG (Scot E Wilcoxon) writes: |In article <20077@cup.portal.com> Bron@cup.portal.com (George Bron Faison) writes: |>It appears that Sql*Forms (or IAP) doesn't want to terminate with the |>"child" process still active. I am assuming that the user exit | |I'm having similar problems with PRO*C (ORACLE's product, not "PRO-C") code. |ORACLE uses SIGCLD and SIGTERM for its own purposes. I've had to |disconnect from ORACLE in order to use child processes and I've seen |ORACLE get stuck until all children terminated. These certainly are |nuisances on UNIX where child processes are useful and in some cases |necessary. Strange, to say the least. Are you sure the wait is caused by a signal? a) A (rather big) Pro*C program we developed here does not have your problem: when a background job is invoked from within the program, the program can be exited without problems. The background job is still running then (this is on Ultrix). b) How can Oracle's SIGCLD handlers affect your program's child processes? Remember that the Oracle process itself has been started up from within the Pro*C program, but that it hasn't started your child processes. How can it check your program's child processes (they are not his children). c) You should check for open (shared) file descriptors (especially those from pipes). Note that a read on a descriptor that has multiple writers only returns EOF after the last writer has closed. When dealing with child processes and pipes the closing of unused pipe descriptors is an important issue (either explicitly closing them or using the close-on-exec flag with fcntl(2)). Your program could well be hanging in a read. B.T.W. As a side note, the pipes that Oracle creates for communication to the Oracle process are not handled too nicely: after creating a child process the child process can access these descriptors. It would have been more correct if these file descriptors had the close-on-exec flag set (so they would close at the child's exec). Leo.