Description | _exit(), _Exit() and exit() terminate the calling process. _Exit is equivalent to _exit. A call to exit triggers the following actions: exit() first calls all functions registered by atexit(), in the reverse order of their registration. If a function registered by a call to atexit() fails to return, the remaining registered functions are not called and the execution of exit() is aborted. If exit() is called more than once, the effects are undefined.
exit() then flushes all output streams, closes all open streams, and removes all files created by tmpfile().
In contrast to exit(), the _exit() function does not call the process termination functions registered with atexit() and does not close the opened files. _exit() and exit() terminate the calling process with the following consequences:
All of the file descriptors, directory streams and message catalog descriptors open in the calling process are closed. If the parent process of the calling process is executing a wait() or waitpid(), it is notified of the termination of the calling process, and the low-order eight bits (i.e. bits 0377) of status are made available to it (see also wait() and waitpid()). If the parent is not waiting, the child ́s status will be made available to it when the parent subsequently executes a wait() or waitpid(). If the parent process of the calling process is not executing a wait() or waitpid(), the calling process is transformed into a zombie process. A zombie process is an inactive process that will be deleted at some later time when its parent process executes a wait() or waitpid(). The termination of a process does not directly terminate its children. The sending of a SIGHUP signal as described below indirectly terminates children in some circumstances. In the POSIX subsystem, the SIGCHLD signal is also sent to the parent process. Other X/Open-compatible implementations may provide alternate mechanisms for this purpose. The parent process ID of all of the calling process's existing child processes and zombie processes is set to the process ID of a special system process. In other words, these processes are inherited by the special system process init (whose process ID is 1). Each attached shared-memory segment is detached, and the value of shm_nattch (see shmget()) in the data structure associated with its shared memory ID is decremented by 1. For each semaphore for which the calling process has set a semadj value (see semop()), that semadj value is added to the semval of the specified semaphore. If the process is a controlling process, the SIGHUP signal will be sent to each process in the foreground process group of the controlling terminal belonging to the calling process. If the process is a controlling process, the controlling terminal associated with the session is disassociated from the session, allowing it to be acquired by a new controlling process. If the exit of the process causes a process group to become orphaned, and if any member of the newly-orphaned process group is stopped, then a SIGHUP signal followed by a SIGCONT signal will be sent to each process in the newly-orphaned process group.
The symbolic names EXIT_SUCCESS and EXIT_FAILURE are defined in stdlib.h and may be used as the value of status to indicate successful or unsuccessful completion. exit() and _exit() do not return.
If threads are used, then the function affects the process or a thread in the following manner: The process is terminated. Threads that are terminated by calling _exit() do not call their cancellation cleanup handler or the data destructors of the thread. BS2000 The monitor job variable MONJV is supplied in accordance with the following rules: Depending on the value of the status argument, the status indicator of the monitoring job variable MONJV (1st to 3rd byte) is set to the value "$T " or "$A ", and the variables SUBCODE1, SUBCODE2 and MAINCODE, which can be queried with the identically named predefined functions of SDF-P, are supplied.
status may contain the symbolic constants EXIT_SUCCESS and EXIT_FAILURE (defined in the header file stdlib.h) or any integer value: EXIT_SUCCESS (value 0)
causes normal program termination. The status indicator of the MONJV is assigned the value "$T ". In addition, the following settings are made: SUBCODE1=0, MAINCODE =CCM0998 and SUBCODE2=status modulo 256 EXIT_FAILURE (value 9990888)
causes a so-called job-step termination: The program is terminated abnormally. In a DO or CALL procedure, the system branches to the next ABEND, END-PROCEDURE, SET-JOB-STEP or LOGOFF command. The system message "ABNORMAL PROGRAM TERMINATION" is issued.
The status indicator of the MONJV is assigned the value "$A ", and SUBCODE1=64, MAINCODE=CCM0999 and SUBCODE2=status modulo 256 are set. integer value != 0 and != 9990888
A job-step termination is performed, and the status indicator of the MONJV is assigned the value "$T". Furthermore, SUBCODE1=64, MAINCODE=CCM0999, and SUBCODE2=status modulo 256 are set. If this value corresponds to the predefined values EXIT_SUCCESS or EXIT_FAILURE, the actions indicated above are performed. (End) |
Notes | Applications should normally use exit() rather than _exit(). Functions registered by at_quick_exit() are not called. BS2000
In order to supply and query monitoring job variables, the C-language program must be started from BS2000 with the command: /START-PROG program,MONJV=monjvname
The contents of the job variables can then be checked, e.g. with the following command: /SHOW-JV JV-NAME(monjvname)
Further information on the use of monitoring job variables for runtime monitoring can be found in the "Job Variables (BS2000)" manual. (End) |
See also | abort(), atexit(), at_quick_exit(), bs2exit(), close(), fclose(), quick_exit(), semop(), shmget(), sigaction(), wait(), stdlib.h, unistd.h.
|
