Re: Pro*C Question: Forking Processes

From: Frank-Michael Zimmer <zimmer_at_dkrz.de>
Date: 1996/08/30
Message-ID: <322720A4.41C67EA6_at_dkrz.de>#1/1


Well, thanks a lot for the comments and suggestions - I think I should specify my problem a bit more:

The program is written in Pro*C and runs on Solaris, with Oracle version 7.1.4.

The idea is of something like a demon that wait at the lower end of a pipe to accept orders. The orders are inserted into the upper pipe end by routines from a package that resides in the database. If you have an order, just call the package procedure, it will turn it into a message, throw that down the pipeline, and the 'demon' will take care of its execution.

To execute the order, the 'demon' has to spawn a child, for the orders might take long to execute (fetch (large!) datasets from the database and write them to a directory - the data may well be migrated into a unitree system), and doing the work himself will block him for too long.

Also, the 'demon' is expected to deliver some kind of receipt upon completion of his task. The method implemented calls another package function. The important point is just that whoever writes the receipt has to be connected to Oracle.

The _real_ problems ;) now are:

  1. Who writes the receipt, and when? Forking while connected means that Oracle sees the last of the two processes that used the database connection as the legitimate owner. Usually, the son writes his receipt and terminates, thereby killing the father's connection, too. On the other hand, if the son does not use his connection but hands his data to the father to write the receipt and simply terminates afterwards, the connection is ok, but the father has to keep track of an undetermined number of children. I did this by having the father use a list of his sons' data, with the effect that a very quickly terminating son will cause the father to remove his son from the list before he has entered him into it! So this does not work, either.
  2. To disconnect, or not to disconnect? Disconnecting, forking and then connecting again so each of the two processes had his own session is a good idea for a solution, but there have been problems in the praxis: After the sons terminate, the father receives a SIGCHLD signal to inform him that there may be a data heirloom for him, to be collected by the system call wait(). The first dead child is removed all right, but any further children that die suffer the grisly fate of a unix zombie... ;) This happens independently of the actual actions the children take with Oracle. I suspect that there is a problem with the father's waiting at the pipe for a message to pop out (a blocking procedure call) being interrupted by the SIGCHLD signal and entering the signal handler. As this mechanism works well when Oracle is not involved, I doubt that it's simply a unix problem.

Ah, well. If you have read this far, I thank you for your patience and would appreciate your thoughts on the subject, just like any ideas or suggestions.

Have a nice weekend,

                    Frank-Michael :D
Received on Fri Aug 30 1996 - 00:00:00 CEST

Original text of this message