Image Threads Investigation Report

can not be within a transaction while forking, either a dynamic transaction or a user logging
transaction. The forking process can not own any locks, no matter if it is a database lock, a
data set lock or a predicate lock. And, of course, the forking process can not be in a
TurboIMAGE intrinsic at the time of forking. If the forking process is enabled for user logging,
even when forking happens between two transactions, one more step needs to be taken: a
fake DBOPEN log record must be written into the log file for the forked process. Otherwise,
DBRECOV will fail to recover the transactions for the forked process.
2.2.2 Global variables
Since the forked process has its own SR5 virtual space, DP-relative global variables should
not be a problem. Somehow, TurboIMAGE needs to find a way to copy the DP-relative global
variables from the forking process to the forked process.
2.2.3 Open files
The forked process inherits the file structures of its parent process by having it own PLFD
(Process Local File Descriptor) but sharing the same GDPD (Global Data Pointer Descriptor).
Because it shares the GDPD, it shares the SMCB
inside the GDPD. Because it shares SMCB,
it has the same issue as threads have.
2.3 Passing "base ID" between processes
The third request in the same arena is passing "base ID" between processes. The processes
may mean threads, or may mean the forking and forked processes, or parent and son
processes, or even two unrelated processes. Before a discussion of this problem, let’s first
understand what the "base ID" is. "Base ID" is a unique number (unique to this process),
which TurboIMAGE returns when a program calls DBOPEN. The program passes a database
name to DBOPEN with the first two-byte set blank. TurboIMAGE, after successfully opening
the database, will put the "base ID" in this two bytes space. Basically, the "base ID" is the
index to an array of pointers, which point to DBUs this process has created. This array is
located in the DBUX control block. For every DBOPEN, TurboIMAGE creates a DBU control
block in the SR5 virtual space. The address of the DBU is then added to the array in the
DBUX, which belongs to this process. So, by getting the "base ID" from all the subsequent
TurboIMAGE intrinsic calls, TurboIMAGE can link the intrinsic call to
the related DBOPEN and
the DBU control block. So, passing "base ID" between processes actually means sharing the
DBU.
Since both DBU and DBUX are considered to be "process local", sharing DBU between
processes is really deflecting the architecture. Many issues will surface by doing that:
¡
What if the process, which receives the "base ID" already has an open database? The
"base ID", which really is an index, may mess up with the one it already has.
¡
Who will be the "owner" of the DBU? What if the ID has been passed through several
hands?
¡
What should the process termination do, if the program is aborting, the DBU is being
purged, but the other process is accessing the DBU?
¡
How should the user logging be handled? For example,
how can DBRECOV handle all
the TurboIMAGE intrinsics without matching DBOPEN?
3.
Options
After gone through various issues for accessing databases via threads or forked processes,
let’s discuss the options for solving these issues. Again, let’s divide them into three different
Page
5
of
9
Image Threads Investigation Report
7/18/2008
http://www.hp.com/cgi
-
bin/pf
-
new.cgi?IN=http://jazz.external.hp.com/papers/image
-
threa
...