12.多进程程序的操作
12.多进程程序的操作
创建进程：
创建进程的函数是fork():
我们来看看帮助文件：man 2 fork:
AME
fork - create a child process
SYNOPSIS
#include <unistd.h>
pid_t fork(void);
DESCRIPTION
fork() creates a new process by duplicating the calling process. The new process,
referred to as the child, is an exact duplicate of the calling process, referred
to as the parent, except for the following points:
* The child has its own unique process ID, and this PID does not match the ID of
any existing process group (setpgid(2)).
* The child's parent process ID is the same as the parent's process ID.
* The child does not inherit its parent's memory locks (mlock(2), mlockall(2)).
* Process resource utilizations (getrusage(2)) and CPU time counters (times(2))
are reset to zero in the child.
* The child's set of pending signals is initially empty (sigpending(2)).
* The child does not inherit semaphore adjustments from its parent (semop(2)).
* The child does not inherit record locks from its parent (fcntl(2)).
* The child does not inherit timers from its parent (setitimer(2), alarm(2),
timer_create(2)).
* The child does not inherit outstanding asynchronous I/O operations from its
parent (aio_read(3), aio_write(3)), nor does it inherit any asynchronous I/O
contexts from its parent (seeio_setup(2)).
The process attributes in the preceding list are all specified in POSIX.1-2001.
The parent and child also differ with respect to the following Linux-specific pro-
cess attributes:
* The child does not inherit directory change notifications (dnotify) from its
parent (see the description of F_NOTIFY in fcntl(2)).
* The prctl(2) PR_SET_PDEATHSIG setting is reset so that the child does not
receive a signal when its parent terminates.
* Memory mappings that have been marked with the madvise(2) MADV_DONTFORK flag
are not inherited across a fork().
* The termination signal of the child is always SIGCHLD (see clone(2)).
Note the following further points:
* The child process is created with a single thread — the one that called fork().
The entire virtual address space of the parent is replicated in the child,
including the states of mutexes, condition variables, and other pthreads
objects; the use of pthread_atfork(3) may be helpful for dealing with problems
that this can cause.
* The child inherits copies of the parent's set of open file descriptors. Each
file descriptor in the child refers to the same open file description (see
open(2)) as the corresponding file descriptor in the parent. This means that
the two descriptors share open file status flags, current file offset, and sig-
nal-driven I/O attributes (see the description of F_SETOWN and F_SETSIG in
fcntl(2)).
* The child inherits copies of the parent's set of open message queue descriptors
(see mq_overview(7)). Each descriptor in the child refers to the same open
message queue description as the corresponding descriptor in the parent. This
means that the two descriptors share the same flags (mq_flags).
* The child inherits copies of the parent's set of open directory streams (see
opendir(3)). POSIX.1-2001 says that the corresponding directory streams in the
parent and child may share the directory stream positioning; on Linux/glibc
they do not.
RETURN VALUE
On success, the PID of the child process is returned in the parent, and 0 is
returned in the child. On failure, -1 is returned in the parent, no child process
is created, and errno is set appropriately.
ERRORS
EAGAIN fork() cannot allocate sufficient memory to copy the parent's page tables
and allocate a task structure for the child.
EAGAIN It was not possible to create a new process because the caller's
RLIMIT_NPROC resource limit was encountered. To exceed this limit, the
process must have either the CAP_SYS_ADMIN or the CAP_SYS_RESOURCE capabil-
ity.
ENOMEM fork() failed to allocate the necessary kernel structures because memory is
tight.
CONFORMING TO
SVr4, 4.3BSD, POSIX.1-2001.
NOTES
Under Linux, fork() is implemented using copy-on-write pages, so the only penalty
that it incurs is the time and memory required to duplicate the parent's page
tables, and to create a unique task structure for the child.
Since version 2.3.3, rather than invoking the kernel's fork() system call, the
glibc fork() wrapper that is provided as part of the NPTL threading implementation
invokes clone(2) with flags that provide the same effect as the traditional system
call. The glibc wrapper invokes any fork handlers that have been established
using pthread_atfork(3).
EXAMPLE
See pipe(2) and wait(2).
SEE ALSO
clone(2), execve(2), setrlimit(2), unshare(2), vfork(2), wait(2), daemon(3), capa-
bilities(7), credentials(7)
COLOPHON
This page is part of release 3.22 of the Linux man-pages project. A description
of the project, and information about reporting bugs, can be found at
http://www.kernel.org/doc/man-pages/.
创建一个进程的函数是fork()。函数的原型：
pid_t fork(void);
该函数的功能是创建一个子进程。需要的头文件：unistd.h。
该函数的返回值：在成功的情况下返回两个：
-
在父进程中返回子进程的PID。
-
在子进程中返回的是0.
在失败的情况下：返回的是-1.
该函数是没有参数的。
实例：multiprocess.c:
#include <unistd.h>
#include <stdio.h>
void main(){
fork();
printf("process is me \n");
exit(0);
}
运行的结果：
我们从运行的结果看到，程序运行一次，printf打印了两次信息。这就是fork函数产生的。当一个进程调用了fork函数后，会产生一个子进程，子进程开始运行的位置是fork函数之后的第一行开始运行。该子进程的参数是复制父进程的初始参数的参数。
我们从上面知道，进程调用fork函数会返回两个值：父进程返回子进程的PID，子进程返回0.由此我们可以根据他们返回值的不同，可以使他们去实现不同的功能。
我们来看下面的例子：
muitiprocess1.c:
#include <unistd.h>
#include <stdio.h>
void main(){
pid_t pid;
pid = fork();
if(pid > 0){
printf("hello father process!\n");
exit(0);
}
else{
printf("hello child process!\n");
exit(0);
}
}
运行的结果：
这就实现了父子进程做不同的事情。
另外一个创建进程的函数是：vfork：
查看帮助文档：man 2 vfork:
NAME
vfork - create a child process and block parent
SYNOPSIS
#include <sys/types.h>
#include <unistd.h>
pid_t vfork(void);
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
vfork(): _BSD_SOURCE || _XOPEN_SOURCE >= 500
DESCRIPTION
Standard Description
(From POSIX.1) The vfork() function has the same effect as fork(2), except that
the behavior is undefined if the process created by vfork() either modifies any
data other than a variable of type pid_t used to store the return value from
vfork(), or returns from the function in which vfork() was called, or calls any
other function before successfully calling _exit(2) or one of the exec(3) family
of functions.
Linux Description
vfork(), just like fork(2), creates a child process of the calling process. For
details and return value and errors, see fork(2).
vfork() is a special case of clone(2). It is used to create new processes without
copying the page tables of the parent process. It may be useful in performance-
sensitive applications where a child will be created which then immediately issues
an execve(2).
vfork() differs from fork(2) in that the parent is suspended until the child ter-
minates (either normally, by calling _exit(2), or abnormally, after delivery of a
fatal signal), or it makes a call to execve(2). Until that point, the child
shares all memory with its parent, including the stack. The child must not return
from the current function or call exit(3), but may call _exit(2).
Signal handlers are inherited, but not shared. Signals to the parent arrive after
the child releases the parent's memory (i.e., after the child terminates or calls
execve(2)).
Historic Description
Under Linux, fork(2) is implemented using copy-on-write pages, so the only penalty
incurred by fork(2) is the time and memory required to duplicate the parent's page
tables, and to create a unique task structure for the child. However, in the bad
old days a fork(2) would require making a complete copy of the caller's data
space, often needlessly, since usually immediately afterwards an exec(3) is done.
Thus, for greater efficiency, BSD introduced the vfork() system call, which did
not fully copy the address space of the parent process, but borrowed the parent's
memory and thread of control until a call to execve(2) or an exit occurred. The
parent process was suspended while the child was using its resources. The use of
vfork() was tricky: for example, not modifying data in the parent process depended
on knowing which variables are held in a register.
CONFORMING TO
4.3BSD, POSIX.1-2001. POSIX.1-2008 removes the specification of vfork(). The
requirements put on vfork() by the standards are weaker than those put on fork(2),
so an implementation where the two are synonymous is compliant. In particular,
the programmer cannot rely on the parent remaining blocked until the child either
terminates or calls execve(2), and cannot rely on any specific behavior with
respect to shared memory.
NOTES
Linux Notes
Fork handlers established using pthread_atfork(3) are not called when a multi-
threaded program employing the NPTL threading library calls vfork(). Fork han-
dlers are called in this case in a program using the LinuxThreads threading
library. (See pthreads(7) for a description of Linux threading libraries.)
History
The vfork() system call appeared in 3.0BSD. In 4.4BSD it was made synonymous to
fork(2) but NetBSD introduced it again, cf. http://www.netbsd.org/Documenta-
tion/kernel/vfork.html . In Linux, it has been equivalent to fork(2) until
2.2.0-pre6 or so. Since 2.2.0-pre9 (on i386, somewhat later on other architec-
tures) it is an independent system call. Support was added in glibc 2.0.112.
BUGS
It is rather unfortunate that Linux revived this specter from the past. The BSD
man page states: "This system call will be eliminated when proper system sharing
mechanisms are implemented. Users should not depend on the memory sharing seman-
tics of vfork() as it will, in that case, be made synonymous to fork(2)."
Details of the signal handling are obscure and differ between systems. The BSD
man page states: "To avoid a possible deadlock situation, processes that are chil-
dren in the middle of a vfork() are never sent SIGTTOU or SIGTTIN signals; rather,
output or ioctls are allowed and input attempts result in an end-of-file indica-
tion."
SEE ALSO
clone(2), execve(2), fork(2), unshare(2), wait(2)
COLOPHON
This page is part of release 3.22 of the Linux man-pages project. A description
of the project, and information about reporting bugs, can be found at
http://www.kernel.org/doc/man-pages/.
Vfork的函数的原型是：
pid_t vfork(void);
该函数的功能是创建一个子进程，并阻塞父进程。这就决定了在调用vfork函数创建子进程的时候，先执行子进程，后再执行父进程。而上面的fork函数则次序是不一定谁先执行。
需要的头文件：
<sys/types.h> <unistd.h>
返回值是：成功：
-
在父进程中返回子进程的PID。
-
在子进程中返回的是0.
失败则返回-1.
没有参数。
实例：multiprocess2.c:
#include <unistd.h>
#include <stdio.h>
void main(){
pid_t pid;
pid = vfork();
if(pid > 0){
printf("hello father process!\n");
exit(0);
}
else{
printf("hello child process!\n");
exit(0);
}
}
运行的结果：
这就是vfork的一个例子，我们看到结果是先执行子进程后执行父进程。这是fork和vfork的一个不同点。还有一个不同点事：fork的父子进程使用不同但是初始条件相同的变量环境，即是栈，就是他们的各自的变量环境，初始条件是相同的。而vfork则是父子进程共用一个变量环境。
Count.c:
#include <unistd.h>
#include <stdio.h>
void main(){
pid_t pid;
int count = 0;
pid = fork();
count = count + 1;
printf("count is %d \n",count);
exit(0);
}
运行的结果：
实例:vcount.c:
#include <unistd.h>
#include <stdio.h>
void main(){
pid_t pid;
int count = 0;
pid = vfork();
count = count + 1;
printf("count is %d \n",count);
exit(0);
}
程序运行的结果：
这跟我们fork和vfork的区别。
进程退出：
帮助文档的信息：man 2 exit:
NAME
_exit, _Exit - terminate the calling process
SYNOPSIS
#include <unistd.h>
void _exit(int status);
#include <stdlib.h>
void _Exit(int status);
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
_Exit(): _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99
DESCRIPTION
The function _exit() terminates the calling process "immediately". Any open file
descriptors belonging to the process are closed; any children of the process are
inherited by process 1, init, and the process's parent is sent a SIGCHLD signal.
The value status is returned to the parent process as the process's exit status,
and can be collected using one of the wait(2) family of calls.
The function _Exit() is equivalent to _exit().
RETURN VALUE
These functions do not return.
CONFORMING TO
SVr4, POSIX.1-2001, 4.3BSD. The function _Exit() was introduced by C99.
NOTES
For a discussion on the effects of an exit, the transmission of exit status, zom-
bie processes, signals sent, etc., see exit(3).
The function _exit() is like exit(3), but does not call any functions registered
with atexit(3) or on_exit(3). Whether it flushes standard I/O buffers and removes
temporary files created with tmpfile(3) is implementation-dependent. On the other
hand, _exit() does close open file descriptors, and this may cause an unknown
delay, waiting for pending output to finish. If the delay is undesired, it may be
useful to call functions like tcflush(3) before calling _exit(). Whether any
pending I/O is canceled, and which pending I/O may be canceled upon _exit(), is
implementation-dependent.
In glibc up to version 2.3, the _exit() wrapper function invoked the kernel system
call of the same name. Since glibc 2.3, the wrapper function invokes
exit_group(2), in order to terminate all of the threads in a process.
SEE ALSO
execve(2), exit_group(2), fork(2), kill(2), wait(2), wait4(2), waitpid(2),
atexit(3), exit(3), on_exit(3), termios(3)
COLOPHON
This page is part of release 3.22 of the Linux man-pages project. A description
of the project, and information about reporting bugs, can be found at
http://www.kernel.org/doc/man-pages/.
在父进程中可以使用return 和exit来退出进程：
成功：return 0 或 exit(0).如果异常则return 1 或exit(1).
return是语言级别的，不管你用不用都是存在的，它表示了调用堆栈的返回；而exit是操作系统中系统调用级别的，它表示了一个进程的结束。当然如果是mian函数中return（0）跟exit（0）是等效的。
Multiprocess1.c:
#include <unistd.h>
#include <stdio.h>
void main(){
pid_t pid;
pid = fork();
if(pid > 0){
printf("hello father process!\n");
return 0;
//exit(0);
}
else{
printf("hello child process!\n");
exit(0);
}
}
运行的结果：
上面的程序中使用了return，正常退出父进程。
Multiprocess2.c:
#include <unistd.h>
#include <stdio.h>
void main(){
pid_t pid;
pid = fork();
if(pid > 0){
printf("hello father process!\n");
return 0;
//exit(0);
}
else{
printf("hello child process!\n");
return 0;
//exit(0);
}
}
运行的结果：
跟父进程等效。
线程等待：
Man的信息：man 2 wait:
NAME
wait, waitpid, waitid - wait for process to change state
SYNOPSIS
#include <sys/types.h>
#include <sys/wait.h>
pid_t wait(int *status);
pid_t waitpid(pid_t pid, int *status, int options);
int waitid(idtype_t idtype, id_t id, siginfo_t *infop, int options);
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
waitid(): _SVID_SOURCE || _XOPEN_SOURCE
DESCRIPTION
All of these system calls are used to wait for state changes in a child of the
calling process, and obtain information about the child whose state has
changed. A state change is considered to be: the child terminated; the child
was stopped by a signal; or the child was resumed by a signal. In the case of
a terminated child, performing a wait allows the system to release the
resources associated with the child; if a wait is not performed, then the ter-
minated child remains in a "zombie" state (see NOTES below).
If a child has already changed state, then these calls return immediately.
Otherwise they block until either a child changes state or a signal handler
interrupts the call (assuming that system calls are not automatically restarted
using the SA_RESTART flag of sigaction(2)). In the remainder of this page, a
child whose state has changed and which has not yet been waited upon by one of
these system calls is termed waitable.
wait() and waitpid()
The wait() system call suspends execution of the calling process until one of
its children terminates. The call wait(&status) is equivalent to:
waitpid(-1, &status, 0);
The waitpid() system call suspends execution of the calling process until a
child specified by pid argument has changed state. By default, waitpid() waits
only for terminated children, but this behavior is modifiable via the options
argument, as described below.
The value of pid can be:
< -1 meaning wait for any child process whose process group ID is equal to
the absolute value of pid.
-1 meaning wait for any child process.
0 meaning wait for any child process whose process group ID is equal to
that of the calling process.
> 0 meaning wait for the child whose process ID is equal to the value of
pid.
The value of options is an OR of zero or more of the following constants:
WNOHANG return immediately if no child has exited.
WUNTRACED also return if a child has stopped (but not traced via ptrace(2)).
Status for traced children which have stopped is provided even if
this option is not specified.
WCONTINUED (since Linux 2.6.10)
also return if a stopped child has been resumed by delivery of SIG-
CONT.
(For Linux-only options, see below.)
If status is not NULL, wait() and waitpid() store status information in the int
to which it points. This integer can be inspected with the following macros
(which take the integer itself as an argument, not a pointer to it, as is done
in wait() and waitpid()!):
WIFEXITED(status)
returns true if the child terminated normally, that is, by calling
exit(3) or _exit(2), or by returning from main().
WEXITSTATUS(status)
returns the exit status of the child. This consists of the least sig-
nificant 8 bits of the status argument that the child specified in a
call to exit(3) or _exit(2) or as the argument for a return statement in
main(). This macro should only be employed if WIFEXITED returned true.
WIFSIGNALED(status)
returns true if the child process was terminated by a signal.
WTERMSIG(status)
returns the number of the signal that caused the child process to termi-
nate. This macro should only be employed if WIFSIGNALED returned true.
WCOREDUMP(status)
returns true if the child produced a core dump. This macro should only
be employed if WIFSIGNALED returned true. This macro is not specified
in POSIX.1-2001 and is not available on some Unix implementations (e.g.,
AIX, SunOS). Only use this enclosed in #ifdef WCOREDUMP ... #endif.
WIFSTOPPED(status)
returns true if the child process was stopped by delivery of a signal;
this is only possible if the call was done using WUNTRACED or when the
child is being traced (see ptrace(2)).
WSTOPSIG(status)
returns the number of the signal which caused the child to stop. This
macro should only be employed if WIFSTOPPED returned true.
WIFCONTINUED(status)
(since Linux 2.6.10) returns true if the child process was resumed by
delivery of SIGCONT.
waitid()
The waitid() system call (available since Linux 2.6.9) provides more precise
control over which child state changes to wait for.
The idtype and id arguments select the child(ren) to wait for, as follows:
idtype == P_PID
Wait for the child whose process ID matches id.
idtype == P_PGID
Wait for any child whose process group ID matches id.
idtype == P_ALL
Wait for any child; id is ignored.
The child state changes to wait for are specified by ORing one or more of the
following flags in options:
WEXITED Wait for children that have terminated.
WSTOPPED Wait for children that have been stopped by delivery of a signal.
WCONTINUED Wait for (previously stopped) children that have been resumed by
delivery of SIGCONT.
The following flags may additionally be ORed in options:
WNOHANG As for waitpid().
WNOWAIT Leave the child in a waitable state; a later wait call can be used
to again retrieve the child status information.
Upon successful return, waitid() fills in the following fields of the siginfo_t
structure pointed to by infop:
si_pid The process ID of the child.
si_uid The real user ID of the child. (This field is not set on most
other implementations.)
si_signo Always set to SIGCHLD.
si_status Either the exit status of the child, as given to _exit(2) (or
exit(3)), or the signal that caused the child to terminate, stop,
or continue. The si_code field can be used to determine how to
interpret this field.
si_code Set to one of: CLD_EXITED (child called _exit(2)); CLD_KILLED
(child killed by signal); CLD_DUMPED (child killed by signal, and
dumped core); CLD_STOPPED (child stopped by signal); CLD_TRAPPED
(traced child has trapped); or CLD_CONTINUED (child continued by
SIGCONT).
If WNOHANG was specified in options and there were no children in a waitable
state, then waitid() returns 0 immediately and the state of the siginfo_t
structure pointed to by infop is unspecified. To distinguish this case from
that where a child was in a waitable state, zero out the si_pid field before
the call and check for a non-zero value in this field after the call returns.
RETURN VALUE
wait(): on success, returns the process ID of the terminated child; on error,
-1 is returned.
waitpid(): on success, returns the process ID of the child whose state has
changed; if WNOHANG was specified and one or more child(ren) specified by pid
exist, but have not yet changed state, then 0 is returned. On error, -1 is
returned.
waitid(): returns 0 on success or if WNOHANG was specified and no child(ren)
specified by id has yet changed state; on error, -1 is returned. Each of these
calls sets errno to an appropriate value in the case of an error.
ERRORS
ECHILD (for wait()) The calling process does not have any unwaited-for chil-
dren.
ECHILD (for waitpid() or waitid()) The process specified by pid (waitpid()) or
idtype and id (waitid()) does not exist or is not a child of the calling
process. (This can happen for one's own child if the action for SIGCHLD
is set to SIG_IGN. See also the Linux Notes section about threads.)
EINTR WNOHANG was not set and an unblocked signal or a SIGCHLD was caught; see
signal(7).
EINVAL The options argument was invalid.
CONFORMING TO
SVr4, 4.3BSD, POSIX.1-2001.
NOTES
A child that terminates, but has not been waited for becomes a "zombie". The
kernel maintains a minimal set of information about the zombie process (PID,
termination status, resource usage information) in order to allow the parent to
later perform a wait to obtain information about the child. As long as a zom-
bie is not removed from the system via a wait, it will consume a slot in the
kernel process table, and if this table fills, it will not be possible to cre-
ate further processes. If a parent process terminates, then its "zombie" chil-
dren (if any) are adopted by init(8), which automatically performs a wait to
remove the zombies.
POSIX.1-2001 specifies that if the disposition of SIGCHLD is set to SIG_IGN or
the SA_NOCLDWAIT flag is set for SIGCHLD (see sigaction(2)), then children that
terminate do not become zombies and a call to wait() or waitpid() will block
until all children have terminated, and then fail with errno set to ECHILD.
(The original POSIX standard left the behavior of setting SIGCHLD to SIG_IGN
unspecified. Note that even though the default disposition of SIGCHLD is
"ignore", explicitly setting the disposition to SIG_IGN results in different
treatment of zombie process children.) Linux 2.6 conforms to this specifica-
tion. However, Linux 2.4 (and earlier) does not: if a wait() or waitpid() call
is made while SIGCHLD is being ignored, the call behaves just as though SIGCHLD
were not being ignored, that is, the call blocks until the next child termi-
nates and then returns the process ID and status of that child.
Linux Notes
In the Linux kernel, a kernel-scheduled thread is not a distinct construct from
a process. Instead, a thread is simply a process that is created using the
Linux-unique clone(2) system call; other routines such as the portable
pthread_create(3) call are implemented using clone(2). Before Linux 2.4, a
thread was just a special case of a process, and as a consequence one thread
could not wait on the children of another thread, even when the latter belongs
to the same thread group. However, POSIX prescribes such functionality, and
since Linux 2.4 a thread can, and by default will, wait on children of other
threads in the same thread group.
The following Linux-specific options are for use with children created using
clone(2); they cannot be used with waitid():
__WCLONE
Wait for "clone" children only. If omitted then wait for "non-clone"
children only. (A "clone" child is one which delivers no signal, or a
signal other than SIGCHLD to its parent upon termination.) This option
is ignored if __WALL is also specified.
__WALL (since Linux 2.4)
Wait for all children, regardless of type ("clone" or "non-clone").
__WNOTHREAD (since Linux 2.4)
Do not wait for children of other threads in the same thread group.
This was the default before Linux 2.4.
EXAMPLE
The following program demonstrates the use of fork(2) and waitpid(). The pro-
gram creates a child process. If no command-line argument is supplied to the
program, then the child suspends its execution using pause(2), to allow the
user to send signals to the child. Otherwise, if a command-line argument is
supplied, then the child exits immediately, using the integer supplied on the
command line as the exit status. The parent process executes a loop that moni-
tors the child using waitpid(), and uses the W*() macros described above to
analyze the wait status value.
The following shell session demonstrates the use of the program:
$ ./a.out &
Child PID is 32360
[1] 32359
$ kill -STOP 32360
stopped by signal 19
$ kill -CONT 32360
continued
$ kill -TERM 32360
killed by signal 15
[1]+ Done ./a.out
$
Program source
#include <sys/wait.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
int
main(int argc, char *argv[])
{
pid_t cpid, w;
int status;
cpid = fork();
if (cpid == -1) {
perror("fork");
exit(EXIT_FAILURE);
}
if (cpid == 0) { /* Code executed by child */
printf("Child PID is %ld\n", (long) getpid());
if (argc == 1)
pause(); /* Wait for signals */
_exit(atoi(argv[1]));
} else { /* Code executed by parent */
do {
w = waitpid(cpid, &status, WUNTRACED | WCONTINUED);
if (w == -1) {
perror("waitpid");
exit(EXIT_FAILURE);
}
if (WIFEXITED(status)) {
printf("exited, status=%d\n", WEXITSTATUS(status));
} else if (WIFSIGNALED(status)) {
printf("killed by signal %d\n", WTERMSIG(status));
} else if (WIFSTOPPED(status)) {
printf("stopped by signal %d\n", WSTOPSIG(status));
} else if (WIFCONTINUED(status)) {
printf("continued\n");
}
} while (!WIFEXITED(status) && !WIFSIGNALED(status));
exit(EXIT_SUCCESS);
}
}
SEE ALSO
_exit(2), clone(2), fork(2), kill(2), ptrace(2), sigaction(2), signal(2),
wait4(2), pthread_create(3), credentials(7), signal(7)
COLOPHON
This page is part of release 3.22 of the Linux man-pages project. A descrip-
tion of the project, and information about reporting bugs, can be found at
http://www.kernel.org/doc/man-pages/.
线程的等待函数的原型：
pid_t wait(int *status);
该函数的功能是挂起调用的进程，直到其子进程结束。
需要的头文件：
<sys/types.h><sys/wait.h>
该函数的返回值：成功则是返回等待期间执行的那个子进程的ID。
失败则是返回-1.
该函数有一个参数：记录子进程的退出状态。
实例：wait.c:
#include <unistd.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/wait.h>
void main(){
pid_t pid;
pid = fork();
if(pid > 0){
wait(NULL);
printf("hello father process!\n");
exit(0);
}
else{
printf("hello child process!\n");
exit(0);
}
}
运行结果：
程序执行：
程序执行的函数是以函数族的形式存在：
函数名execl：
查看帮助文档：man execl：
NAME
execl, execlp, execle, execv, execvp - execute a file
SYNOPSIS
#include <unistd.h>
extern char **environ;
int execl(const char *path, const char *arg, ...);
int execlp(const char *file, const char *arg, ...);
int execle(const char *path, const char *arg,
..., char * const envp[]);
int execv(const char *path, char *const argv[]);
int execvp(const char *file, char *const argv[]);
DESCRIPTION
The exec() family of functions replaces the current process image with a new
process image. The functions described in this manual page are front-ends for
execve(2). (See the manual page for execve(2) for further details about the
replacement of the current process image.)
The initial argument for these functions is the pathname of a file which is to
be executed.
The const char *arg and subsequent ellipses in the execl(), execlp(), and exe-
cle() functions can be thought of as arg0, arg1, ..., argn. Together they
describe a list of one or more pointers to null-terminated strings that repre-
sent the argument list available to the executed program. The first argument,
by convention, should point to the filename associated with the file being exe-
cuted. The list of arguments must be terminated by a NULL pointer, and, since
these are variadic functions, this pointer must be cast (char *) NULL.
The execv() and execvp() functions provide an array of pointers to null-termi-
nated strings that represent the argument list available to the new program.
The first argument, by convention, should point to the filename associated with
the file being executed. The array of pointers must be terminated by a NULL
pointer.
The execle() function also specifies the environment of the executed process by
following the NULL pointer that terminates the list of arguments in the argu-
ment list or the pointer to the argv array with an additional argument. This
additional argument is an array of pointers to null-terminated strings and must
be terminated by a NULL pointer. The other functions take the environment for
the new process image from the external variable environ in the current pro-
cess.
Special semantics for execlp() and execvp()
The functions execlp() and execvp() will duplicate the actions of the shell in
searching for an executable file if the specified filename does not contain a
slash (/) character. The search path is the path specified in the environment
by the PATH variable. If this variable isn't specified, the default path
":/bin:/usr/bin" is used. In addition, certain errors are treated specially.
If permission is denied for a file (the attempted execve(2) failed with the
error EACCES), these functions will continue searching the rest of the search
path. If no other file is found, however, they will return with errno set to
EACCES.
If the header of a file isn't recognized (the attempted execve(2) failed with
the error ENOEXEC), these functions will execute the shell (/bin/sh) with the
path of the file as its first argument. (If this attempt fails, no further
searching is done.)
RETURN VALUE
If any of the exec() functions returns, an error will have occurred. The
return value is -1, and errno will be set to indicate the error.
ERRORS
All of these functions may fail and set errno for any of the errors specified
for the library function execve(2).
CONFORMING TO
POSIX.1-2001.
NOTES
On some other systems the default path (used when the environment does not con-
tain the variable PATH) has the current working directory listed after /bin and
/usr/bin, as an anti-Trojan-horse measure. Linux uses here the traditional
"current directory first" default path.
The behavior of execlp() and execvp() when errors occur while attempting to
execute the file is historic practice, but has not traditionally been docu-
mented and is not specified by the POSIX standard. BSD (and possibly other
systems) do an automatic sleep and retry if ETXTBSY is encountered. Linux
treats it as a hard error and returns immediately.
Traditionally, the functions execlp() and execvp() ignored all errors except
for the ones described above and ENOMEM and E2BIG, upon which they returned.
They now return if any error other than the ones described above occurs.
SEE ALSO
sh(1), execve(2), fork(2), ptrace(2), fexecve(3), environ(7)
COLOPHON
This page is part of release 3.22 of the Linux man-pages project. A descrip-
tion of the project, and information about reporting bugs, can be found at
http://www.kernel.org/doc/man-pages/.
该函数的一个原型：
int execl(const char *path, const char *arg, ...);
该函数的功能是运行可执行文件。
需要的头文件：<unistd.h>
返回值：成功不返回。
失败：-1
Pathname:可执行文件的路径。
arg:可执行文件需要的参数。以NULL来结束参数。
execl.c:
#include <unistd.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/wait.h>
void main(){
pid_t pid;
pid = fork();
if(pid > 0){
wait(NULL);
printf("hello father process!\n");
exit(0);
}
else{
execl("/bin/ls","ls","/home/forfish",NULL);
printf("hello child process!\n");
exit(0);
}
}
运行的结果：
可以看到他列出了和直接使用ls命令一个的效果。但是没有打印execl后面的打印信息。这是因为当调用execl的时候，他会覆盖掉原有的代码。也就是说，在该程序中，由于调用了execl，结果是子进程的代码被execl的/bin/ls的代码覆盖掉。注意不是产生新进程，只是覆盖。所以，子进程没有打印信息。
Fork与execl对比：
