gtpa2m2g | Application Programming |
TPF Internet server support allows POSIX-compliant servers (Internet server applications) to be written for or ported to the TPF system, usually with only minimal modifications to account for the differences in the TPF implementation. Because of the existing unique architecture of the TPF system, TPF Internet server support consists of a subset of POSIX-compliant application programming interface (API) functions and TPF-unique API functions.
The following discussions assume a basic knowledge of client, server, and UNIX concepts. Suggested references that describe these concepts are:
A process is an address space and the single thread of control that executes within that address space and its required system resources. There is a process block associated with each entry control block (ECB) where process-related information is maintained by the TPF system.
In the TPF system, all active ECBs are part of a process. The system, tpf_cresc, and tpf_fork functions create a child process.
See the TPF C/C++ Language Support User's Guide for more information about the system, tpf_cresc, and tpf_fork functions.
A process ID is a unique, positive number that represents a process. Because the process ID is a unique identifier, it can be used to direct signals between processes. See Signals for more information about signals. The process ID is also used in the tmpnam function; this function returns a temporary file name based on this unique identifier.
Every process also has a parent process ID associated with it. If there is no parent process, the parent process ID is set to 1. For a child process created by the tpf_fork function, the parent process ID is set to the process ID of the parent process.
A process ID is a unique two-part number, 32 bits in length:
The getpid and getppid functions are provided so that an ECB can obtain its process ID and the process ID of its parent process, respectively. See the TPF C/C++ Language Support User's Guide for more information about the getpid and getppid functions.
A process group is a set of related processes and each process has a process group ID associated with it. Most processes, when created, are assigned to their own process groups. However, a child process created by the tpf_fork function is part of the process group of its parent process, so the child process inherits the process group ID of its parent process.
A child process created by the system and tpf_cresc functions inherits the environment list from the parent process. A child process created by the tpf_fork function inherits the following properties from the parent process:
The effective user ID and effective group ID of a child process created by a tpf_fork function are initialized to the effective user ID and effective group ID of the parent process, with the following exceptions:
The saved set-user-ID and saved set-group-ID of a child process created by the tpf_fork function are initialized to the same values as the effective user ID and effective group ID respectively. This enables an application to toggle its effective user ID between the real user ID and the owner ID of the executable file, if applicable.
The following functions have interfaces identical to the POSIX standards. However, because of the unique TPF architecture, there are differences in the way the functions behave; refer to the individual functions in the TPF C/C++ Language Support User's Guide for specific information about the differences.
If Internet server application code written for the UNIX system is ported to the TPF system, these function calls do not necessarily need to be changed, but it is likely that the Internet server application needs some modification to account for the differences.
Because of the unique TPF architecture, there are some functions that cannot be implemented with interfaces identical and behavior similar to the POSIX standards. The following are the TPF-unique functions for process control:
Because the TPF system does not allow a process to be interrupted asynchronously, the tpf_process_signals function is a way for a process to explicitly tell the TPF system to check for and handle outstanding signals.
A signal is a simple method of communication between two processes and is used for processes to communicate with each other about important events.
In the POSIX process model, signals are sent to processes by the system for a number of reasons, synchronously and asynchronously. The SIGCHLD signal is the only signal sent by the TPF system. Additionally, a subset of POSIX signals are implemented in the TPF system and are listed in the description of the signal function in the TPF C/C++ Language Support User's Guide.
Any process can send a signal to any other process if the sending process knows the process ID of the intended receiving process and if one of the following is true:
Sending a signal does not imply that any action will be taken by the receiving process. In the TPF system, incoming signals are only handled by a process when the process explicitly requests that signals be handled. The receiving process can choose to process signals, selectively ignore signals, or not process signals.
The following APIs are used to request the handling of pending signals:
For example, if signals are used by an application to allow a monitoring process to shut down other processes in the application, the monitoring process could do so only if all of the programs in the application periodically issue a sleep, tpf_process_signals, wait, or waitpid function.
The SIGCHLD signal is the only signal that the TPF system sends to a process. When a child process created by the tpf_fork function ends, the TPF system:
Exit status is saved only if the parent process still exists and it handles signals; that is, the SIGCHLD signal disposition is not set to ignore signals (the SIGCHLD signal handler is not set to SIG_IGN).
An application (especially a long-running application) that creates many child processes using the tpf_fork function must periodically check for saved exit status so that the system resources used to save exit status can be freed. If signals are not processed on a periodic basis, there is a potential to deplete system resources. Alternatively, if an application creates child processes using the tpf_fork function, but is not interested in knowing when its child processes end, the application can notify the TPF system to ignore SIGCHLD signals, and as a result, the exit status for the child processes is not saved and the system resources are not tied up.