Open System Services Programmer's Guide

Note 1
You can get the name of a terminal using the ttyname() function or the tty command. OSS
terminal names are in the format /G/ztnt/#pty00nn. The PROCESS_SETINFO_ procedure
requires the Guardian form of a terminal name, which is in the format:
• $ZTN0.#PTY00xx for systems running G-series RVUs.
• $ZTNT.#PTY00xx for systems running H-series RVUs.
To convert from an OSS pathname format to a Guardian filename format, use the
PATHNAME_TO_FILENAME_ procedure.
Performance Considerations
You can improve the performance of your applications with respect to process management by
following these recommendations:
• Minimize the use of the process-creation functions. There is a lot of system overhead involved
in creating processes, so use static server and demon processes whenever possible. Create
a process and do not terminate it until the program no longer needs it.
• Distribute the workload across processors. Specify the processor using the HP extension
functions when creating a process.
• Create processes in one step instead of two. Use the tdm_spawn() or tdm_spawnp()
function instead of calling the fork() or tdm_fork() function followed by one of the exec
or tdm_exec set of functions.
The following subsections illustrate these performance considerations and actions:
• “Using Dynamic Servers Spread Across Available Processors” (page 138)
• “Using Static Servers Spread Across Available Processors” (page 142)
Using Dynamic Servers Spread Across Available Processors
In contrast, Example 38 (page 140) offers a more flexible solution to the programs in the sample
application of Example 26 (page 107) and Example 27 (page 110). This new program uses the
tdm_spawn() function, instead of one of the fork() calls and the execv() call, to allow for
scalability to other processors and for slightly better process-creation performance.
The launcher program in Example 38 is compiled as a linked program file named dlaunch2.
The dynamic server program in Example 27 is compiled as a linked program file named dserver.
(A requester program, shown in Example 44 (page 182), is also compiled as a linked program file
named requester2.) All programs are secured for execution in the current working directory.
In this application, dlaunch2 creates an AF_INET socket and listens for incoming connections
from one or more copies of requester2. Upon receipt of a connection, dlaunch2 starts dserver
in another available processor, using a tdm_spawn() call. dlaunch2 closes the file descriptors
associated with its requester2 connection. dserver, which has inherited file descriptors for
the requester2 connection, handles all work associated with the connection.
Using two terminal sessions, sample dialog for the terminal launching dlaunch2 might be:
/users/chris: ./dlaunch2
dlaunch2 starting in cpu 2
dserver spawn'ed in cpu 0
dserver [cpu 0] - starting
dserver [cpu 0] - message received on fd 0 = hello 1
dserver [cpu 0] - message received on fd 0 = goodbye 1
dserver [cpu 0] - stopping [input closed]
dserver spawn'ed in cpu 1
dserver [cpu 1] - starting
dserver [cpu 1] - message received on fd 0 = hello 2
dserver [cpu 1] - message received on fd 0 = goodbye 2
138 Managing Processes