Chinaunix首页 | 论坛 | 博客
  • 博客访问: 910726
  • 博文数量: 299
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 2493
  • 用 户 组: 普通用户
  • 注册时间: 2014-03-21 10:07
个人简介

Linux后台服务器编程。

文章分类

全部博文(299)

文章存档

2015年(2)

2014年(297)

分类: LINUX

2014-08-16 14:25:38

Besides the open files, numerous other properties of the parent are inherited by the
child:
Real user ID, real group ID, effective user ID, and effective group ID
Supplementary group IDs
Process group ID
Session ID
Controlling terminal
The set-user-ID and set-group-ID flags
Current working directory
Root directory
File mode creation mask
Signal mask and dispositions
The close-on-exec flag for any open file descriptors
Environment
Attached shared memory segments
Memory mappings
Resource limits

The differences between the parent and child are
? The return values from fork are different.
? The process IDs are different.
? The two processes have different parent process IDs: the parent process ID of the
child is the parent; the parent process ID of the parent doesn’t change.
? The child’s tms_utime, tms_stime, tms_cutime, and tms_cstime values
are set to 0 (these times are discussed in Section 8.17).
? File locks set by the parent are not inherited by the child.
? Pending alarms are cleared for the child.
? The set of pending signals for the child is set to the empty set.
Many of these features haven’t been discussed yet—we’ll cover them in later chapters.



exec:
We’ve mentioned that the process ID does not change after an exec, but the new
program inherits additional properties from the calling process:
? Process ID and parent process ID
? Real user ID and real group ID
? Supplementary group IDs
? Process group ID
? Session ID
? Controlling terminal
? Time left until alarm clock
? Current working directory
? Root directory
? File mode creation mask
? File locks
? Process signal mask
? Pending signals
? Resource limits
? Nice value (on XSI-conformant systems; see Section 8.16)
? Values for tms_utime, tms_stime, tms_cutime, and tms_cstime
The handling of open files depends on the value of the close-on-exec flag for each
descriptor.


当一个进程调用fork时,因为子进程在开始时复制父进程的存储映像,信号捕捉函数的地址在子进程中是有意义的,所以子进程继承父进程的信号处理方式。

特殊的是exec,因为exec运行新的程序后会覆盖从父进程继承来的存储映像,那么信号捕捉函数在新程序中已无意义,所以exec会将原先设置为要捕捉的信号都更改为默认动作。

1,fork后子进程会继承父进程的信号屏蔽字,再继续exec后仍会继承这个信号屏蔽字。同样地,直接调用system后子进程也会继承父进程的信号屏蔽字。

2,fork后子进程会继承父进程的信号处理设置,再继续exec后就不会继承这个信号处理设置了。

3,fork后子进程会继承父进程的控制终端,且子进程在父进程的进程组和会话组中;再继续exec后仍会继承这个控制终端,仍在父进程的进程组和会话组中。同样地,调用system后子进程会继承父进程的控制终端,且子进程在父进程的进程组和会话组中。

4,Ctrl+c产生的SIGINT信号会发送给父进程、fork后的子进程以及继续exec的子进程;同样地,也会发给system调用运行的子进程。


当一个进程调用fork时,因为子进程在开始时复制父进程的存储映像,信号捕捉函数的地址在子进程中是有意义的,所以子进程继承父进程的信号处理方式。
特殊的是exec,因为exec运行新的程序后会覆盖从父进程继承来的存储映像,那么信号捕捉函数在新程序中已无意义,所以exec会将原先设置为要捕捉的信号都更改为默认动作。

阅读(4861) | 评论(1) | 转发(0) |
0

上一篇:unix域套接字

下一篇:Linux多线程信号总结

给主人留下些什么吧!~~

wojiushiwolh2017-03-10 16:32:11

您好,首先感谢您的分享,可我还是有个问题无法解答,就是我设置了SIGINT的捕捉函数,但是当程序在运行exec出来的新程序时我的捕捉函数竟然任然有效,这是为什么?我测试的办法就是在在父进程和exec出来的新程序里调用sleep等待我输入信号来看反应