mod.std.unix P1003 job control proposal
Moderator, John Quarterman
std-unix at ut-sally.UUCP
Sun Oct 12 11:38:15 AEST 1986
From: im4u!caip!hplabs!hpda!hpisoa1!davel at sally.utexas.edu (Dave Lennert)
Date: Thu, 9 Oct 86 14:06:30 pdt
Attached is the P1003 job control proposal. The first file contains
the text as accepted at the September P1003 meeting in Palo Alto.
Note that this text sometimes replaces, and sometimes augments,
existing POSIX text. The second file contains the problems noticed
since then and the proposed resolutions.
Dave Lennert ucbvax!hpda!davel [UUCP]
Hewlett-Packard - 47UX ihnp4!hplabs!hpda!davel [UUCP]
19447 Pruneridge Ave. hpda!davel at ucb-vax.ARPA [ARPA]
Cupertino, CA 95014 (408) 447-6325 [AT&T]
# This is a shell archive. Remove anything before this line,
# then unpack it by saving it in a file and typing "sh file".
#
# Wrapped by davel at hpisoa1 on Thu Oct 9 13:23:24 1986
#
# This archive contains:
# acceptedtext problems
#
echo x - acceptedtext
cat >acceptedtext <<'@EOF'
IEEE
SYSTEM FOR COMPUTER ENVIRONMENTS Std 1003.1
2.3 General Terms
Replace or add the following definitions:
job control option
Job control allows users to selectively stop (suspend)
the execution of processes and continue (resume) their
execution at a later point. The user typically
employs this facility via the interactive interface
jointly supplied by the terminal I/O driver and a
command interpreter. Conforming implementations may
optionally support job control facilities (see
Symbolic Constants 2.10). Portions of the standard
operating system interface which are required only on
implementations which support the job control option
are so labelled.
process group leader
A process group leader is a process whose process ID
is the same as its process group ID. Any process that
is not a process group leader may detach itself from
its process group and becomes the process group leader
of a new process group by calling either the setpgrp()
or setpgrp2() function, which can cause a process to
become either a session process group leader or a job
process group leader, respectively. Job process group
leaders can exist on implementations which support the
job control option.
saved process group ID
An active process has a saved process group ID that is
set to the saved process group ID of the parent
process at the time of creation of the process (via
the fork() function). It is reset to the process
group ID of the process when the process successfully
calls one of the exec functions.
2.10 Symbolic Constants
Add the following new constant after the IEEE1003 constant
defintion:
IEEE1003job
If this symbol is defined then the implementation
supports the job control option.
----------------------------------------------------------------------
IEEE
SYSTEM FOR COMPUTER ENVIRONMENTS Std 1003.1
3.2.1 Wait for Process Termination
Functions: wait(), wait2()
3.2.1.1 Synopsis
Add the following at the end of the section:
#include <sys/wait.h>
int wait2 (stat_loc, options)
int *stat_loc;
int options;
3.2.1.2 Description
Add the following at the end of the section:
If the wait2() variant is used, then there are two options
available for modifying the behavior of the system call.
They may be combined by oring them together. The first is
WNOHANG which prevents wait2() from suspending the calling
process even if there are children to wait for. In this
case, a value of zero is returned indicating there are no
children which have stopped or died. If the second option
WUNTRACED is set, wait2() will also return information when
children of the current process are stopped because they
received a SIGTTIN, SIGTTOU, SIGTSTP, or SIGSTOP signal.
The wait2() function is provided if the implementation
supports the job control option.
3.2.1.3 Returns
Add the following at the end of the section:
If wait2() is called, the WNOHANG option is used, and there
are no stopped or terminated children, then a value of zero
is returned. Otherwise, a value of -1 is returned and errno
shall be set to indicate the error.
----------------------------------------------------------------------
IEEE
SYSTEM FOR COMPUTER ENVIRONMENTS Std 1003.1
In section 3.2.2.2 Description of the _exit function replace
the paragraph:
If the process is a process group leader, the SIGHUP
signal may be sent to each process that has a process
group ID equal to that of the calling process.
with:
If the process is a session process group leader, the
SIGHUP signal may be sent to each process that has a
process group ID equal to that of the calling process;
also, all such processes may have their process group
ID set to zero.
If the implementation supports the job control option
and if the calling process has child processes that
are stopped, they will be sent SIGHUP and SIGCONT
signals.
----------------------------------------------------------------------
IEEE
SYSTEM FOR COMPUTER ENVIRONMENTS Std 1003.1
3.3.1 Signal Names
3.3.1.2 Description
Add the following at the end of the signals list.
SIGCLD + child process terminated
If the implementation supports the job control option then
the following are defined:
SIGSTOP # stop (cannot be caught or ignored)
SIGTSTP # stop signal generated from keyboard
SIGTTIN # background read attempted from control terminal
SIGTTOU # background write attempted to control terminal
SIGCONT %+ continue after stop
+ Indicates that the action on SIG_DFL is to ignore the
signal, rather than terminate the process.
# Indicates that the action on SIG_DFL is to stop rather
than terminate the process.
% Indicates that the signal will not be held off by a
stopped process.
----------------------------------------------------------------------
IEEE
SYSTEM FOR COMPUTER ENVIRONMENTS Std 1003.1
In section 3.3.2.2 Description of the kill() function, add
the following paragraph at the end of the Description
section.
As a single special case on implementations that support the
job control option, the continue signal SIGCONT can be sent
to any process that is a descendant of the current process.
----------------------------------------------------------------------
IEEE
SYSTEM FOR COMPUTER ENVIRONMENTS Std 1003.1
3.3.3 Signal Processing
3.3.3.2 Description
Replace the SIG_DFL and SIG_IGN discussions with the
following text. (Note that this text needs rewording based
on the signal working group decisions from Palo Alto, 9/86.
Bob Lenk is planning on merging this text with the proposal
he sends you. So you should only have to verify that he has
done this.)
SIG_DFL - signal specific default action
For all signals listed in the table in <signal.h>
3.3.1, unless otherwise indicated the default action
is either simple abnormal termination or abnormal
termination with actions of the receiving process.
The result of abnormal termination with actions is
implementation-dependent. Abnormal termination with
actions may result in the creation of a file named
core in the receiving process's current directory.
Such a core file should contain sufficient information
to document the state of the process at the time of
the signal.
For certain indicated signals listed in the table in
<signal.h> 3.3.1, the default action is to stop
(suspend) the receiving process. While a process is
stopped, any additional signals that are sent to the
process will be held off until the process is
continued. An exception to this is SIGCONT which
always causes the receiving process to continue if it
is stopped. When a process is continued, pending
signals will be processed.
For certain indicated signals listed in the table in
<signal.h> 3.3.1, the default action is to ignore
the signal.
Signals not described <signal.h> 3.3.1 may have
other default actions.
SIG_IGN - ignore signal
The signal sig is to be ignored. The signals SIGKILL
and SIGSTOP shall not be ignored. Ignoring SIGCLD may
cause terminating children to be ignored by the wait
functions 3.2.1.
At the end of the "function address - catch signal"
discussion, replace the statement:
The signal SIGKILL cannot be caught.
with:
The signals SIGKILL and SIGSTOP cannot be caught.
3.3.3.4 Errors
Replace:
[EINVAL] The value sig is either an illegal signal number or
SIGKILL.
with:
[EINVAL] The value sig is either an illegal signal number,
or is equal to SIGKILL or SIGSTOP.
----------------------------------------------------------------------
IEEE
SYSTEM FOR COMPUTER ENVIRONMENTS Std 1003.1
Replace all of section 4.3.1 with:
4.3.1 Get Process Group ID
Functions: getpgrp(), getpgrp2()
4.3.1.1 Synopsis
int getpgrp ( )
int getpgrp2 (pid)
int pid;
4.3.1.2 Description
The getpgrp() function returns the process group ID of the
calling process.
The getpgrp2() function returns the process group ID of the
specified process. If pid is zero, the call applies to the
current process. For this to be allowed, the real or
effective user ID of the current process must match the real
or effective user ID of the referenced process, the
effective user ID of the current process must be super-user,
or the referenced process must be a descendant of the
current process. The saved set-user ID of the referenced
process may be checked in place of its effective user ID.
The getpgrp2() function is provided if the implementation
supports the job control option.
4.3.1.3 Returns
The getpgrp() function returns the process group ID of the
calling process.
Upon successful completion, the getpgrp2() function returns
the process group ID of the specified process. Otherwise a
value of -1 is returned and errno is set to indicate the
error.
4.3.1.4 Errors
If the getpgrp2() function returns -1, the value stored in
errno may be interpreted as follows:
[EPERM] The effective user ID of the current process is
not super-user, the real or effective user ID of
the current process does not match the real or
effective user ID (or saved set-user ID) of the
specified process, and the specified process is
not a descendant of the current process.
[ESRCH] No process can be found corresponding to that
specified by pid.
4.3.1.5 References
setpgrp() 4.3.2, signal() 3.3.3.
----------------------------------------------------------------------
IEEE
SYSTEM FOR COMPUTER ENVIRONMENTS Std 1003.1
Replace all of section 4.3.2 with:
4.3.2 Set Process Group
Functions: setpgrp(), setpgrp2()
4.3.2.1 Synopsis
int setpgrp ( )
int setpgrp2 (pid, pgrp)
int pid, pgrp;
4.3.2.2 Description
The setpgrp() function sets the process group ID of the
calling process to the process ID of the calling process and
returns the new process group ID. The calling process
becomes a session process group leader.
The setpgrp() function relinquishes the process's
controlling terminal unless the process is already the
process group leader.
The setpgrp2() function sets the process group ID of the
process specified by pid to be pgrp. If pid is zero, the
process group ID of the calling process will be affected.
If the affected process's new process group ID is the same
as its process ID then the affected process becomes a job
control process group leader.
The setpgrp2() function does not affect the process's
controlling terminal.
The setpgrp2() function is provided if the implementation
supports the job control option.
The following condition must be met for the setpgrp2()
function to succeed; otherwise, the error [EINVAL] is
returned:
The value of pgrp must be in the range of valid process
group ID values, or it must be zero ("no process
group").
In addition, one or more of the following conditions must be
met for the setpgrp2() function to succeed; otherwise, the
error [EPERM] is returned:
The effective user ID of the calling process is super-
user.
The affected process is a descendant of the calling
process.
The real or effective user ID of the calling process
matches the real or effective user ID of the affected
process. The saved set-user ID of the affected process
may be checked in place of its effective user ID.
In addition, one or more of the following conditions must be
met for the setpgrp2() function to succeed, otherwise, the
error [EPERM] is returned:
The effective user ID of the calling process is super-
user.
The value of pgrp matches the saved process group ID of
the calling process.
All processes with a process ID or process group ID
that is the same as pgrp have the same real or
effective user ID as the real or effective user ID of
the calling process, or are descendants of the calling
process. The saved set-user ID of the related
processes may be checked in place of their effective
user ID.
4.3.2.3 Returns
The setpgrp() function returns the value of the new process
group ID.
Upon successful completion, the setpgrp2() function returns
a value of 0. Otherwise, a value of -1 is returned and
errno is set to indicate the error.
4.3.2.4 Errors
If the setpgrp2() function returns -1, the value stored in
errno may be interpreted as follows:
[ESRCH] No process can be found corresponding to that
specified by pid.
[EPERM] The effective user ID of the calling process is
not super-user; and the real or effective user
ID of the calling process does not match the
real or effective user ID (or saved set-user ID)
of the specified process; and the specified
processes are not descendants of the calling
process.
[EPERM] The effective user ID of the calling process is
not super-user; and the value pgrp does not
match the saved process group ID of calling
process; and a process exists that is not a
descendant of the calling process and whose
process ID or process group ID match pgrp, while
neither the real or effective user ID (or saved
set-user ID) of this process match either the
real or effective user ID of the calling
process.
[EINVAL] The value for pgrp is outside the range of valid
process group ID values and is non-zero.
4.3.2.5 References
exec 3.1.2, _exit() 3.2.2, fork() 3.1.1, getpid()
4.1.1, kill() 3.3.2, signal() 3.3.3.
----------------------------------------------------------------------
IEEE
SYSTEM FOR COMPUTER ENVIRONMENTS Std 1003.1
Alter the forthcoming reliable signals proposal, the
sigvector() description, by adding the following paragraph:
The sv_flags field can be used to modify the receipt the
specified signal. If sig is SIGCLD and the implementation
supports the job control option, the following flag bit can
be set in sv_flags:
SV_CLDSTOP Also generate SIGCLD when children stop
@EOF
chmod 664 acceptedtext
echo x - problems
cat >problems <<'@EOF'
There are two omissions in the job control specification that
have come to light since it was accepted at the P1003 meeting
in Palo Alto. There will be forthcoming proposals to correct
these.
Omission 1:
Bob Lenk noticed that, in adding SIGCLD to the required portion of
POSIX, we neglected to deal with the issue of what happens when
SIGCLD is set to SIG_IGN. Specifically, on ATT this causes
terminated children to be invisible to wait*() while on BSD there
is no such side effect. Bob Lenk feels the best way to handle this
is to disallow conforming applications from setting SIGCLD to SIG_IGN.
(There is no advantage to using SIG_IGN over SIG_DFL in the case
of SIGCLD anyway.) Bob is planning on submitting a cleanup proposal
proposing this.
Omission 2:
Doug Gwyn pointed out the following omission:
The changes to section 3.2.1.2 for wait2() did not contain a
description of the returned status information in the case
of stopped children.
I've submitted a proposal to add the following additional text:
[OLD TEXT FOR CONTEXT:]
wait2() will also return information when children of the
current process are stopped because they received a SIGTTIN,
SIGTTOU, SIGTSTP, or SIGSTOP signal.
[NEW TEXT:]
In this case, the status information can also be interpreted
in the following way:
If the child process stopped, the 8 bits of status
(corresponding to the octal value 0177400) will contain
the number of the signal that caused the process to
stop and the low order 8 bits corresponding to the
octal value 0377 will be set equal to the octal value
0177.
@EOF
chmod 664 problems
exit 0
Volume-Number: Volume 7, Number 53
More information about the Mod.std.unix
mailing list