Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!cica!ctrsol!ginosko!uunet!mcvax!hp4nl!phigate!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.databases
Subject: Re: Oracle iap user exits
Message-ID: <1054@philmds.UUCP>
Date: 6 Jul 89 11:18:20 GMT
References: <1197@pyrltd.UUCP> <20077@cup.portal.com> <10915@datapg.MN.ORG>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 38

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.