Re: On fork's, wait's, SIGCHLD and Pro*C

From: Georg Rehfeld <georg_at_deerwood.hanse.de>
Date: Fri, 3 Sep 1993 11:03:51 GMT
Message-ID: <1993Sep3.110351.625_at_deerwood.hanse.de>


In article <CCCLo6.Ev0_at_max.uis.com> you wrote:
> ....
> - in the meantime, the parent process goes back
> to the select() to look for more action.
> however, before it gets back to the select(), it
> does a CONNECT, followed by some SQL, and then a
> COMMIT RELEASE. Only then does it return to the
> select().
> ....
> We are having a problem in that sometimes the PID associated with
> one of our children is never returned by waitpid(), therefore we
> never get the file descriptor back in the select().
> ....
> My hypothesis is that the CONNECT statement fork's a child to do
> SQL stuff. Then the RELEASE tells the child to exit, and then
> performs a wait() to clean up after itself. Unfortunately, the
> above conditions lead me to believe that RELEASE is, in fact,
> wait'ing for any and all children, thereby eating my PIDs as well
> as its own.

Your guess is right, the Oracle libraries fiddle around with several signals. If you ask Oracle, they will give you some copies with examples, how to use the signals, they require (mainly: save old signal-handler, install own handler, use it for some time, install back the old handler). And, if I recall right, you get the list of signals, they use.

For a workaround: fork a new child to do the CONNECT ... COMMIT RELEASE, so it will wait for it's Oracle child, but not for yours.

Georg

--
 ___   ___
| + | |__ ' Georg Rehfeld,  D-20535 Hamburg, Jordanstr. 8,  [49] (40) 2518356
|_|_\ |___, georg_at_deerwood.hanse.de
-- 
 ___   ___
| + | |__ ' Georg Rehfeld,  D-20535 Hamburg, Jordanstr. 8,  [49] (40) 2518356
|_|_\ |___, georg_at_deerwood.hanse.de
Received on Fri Sep 03 1993 - 13:03:51 CEST

Original text of this message