| ||
登录  注册
搜索
自选风格
返回旧界面
|
|
 荔园晨风BBS →
电脑技术 →
网络安全 →
保留区文章阅读
|
| 保留区文章阅读 [返回] |
|---|
|
发信人: bstone (Back to real world!), 信区: Hacker 标 题: unix环境高级编程--第8章 进程控制（上） 发信站: BBS 荔园晨风站 (Wed Mar 29 08:40:42 2000), 转信 发信人: scircle (yuanyuan), 信区: Security 标 题: unix环境高级编程--第8章 进程控制（上） 发信站: BBS 水木清华站 (Mon Mar 27 15:58:55 2000) 第八章〓进程控制 81〓引言 本章介绍Unix的进程控制，包括创建新进程、执行程序和进程终止。我们也说明进 程的各种 ID〖CD2〗实际、有效和保存的用户和组ID，以及它们如何受到进程控制原语的影 响。本章 也包括了解释器文件和system函数。本章以大多数Unix系统所提供的进程会计机制 结束。这 使我们从一个不同角度了解进程控制功能。 82〓进程标识 每个进程都有一个非负整型的唯一进程ID。因为进程ID标识符总是唯一的，常将其 用作为其 它标识符的一部分以保证其唯一性。在513节中的tmpnam函数将进程ID作为名字 的一部分 创建一个唯一的路径名。 有某些专用的进程：进程ID0是调度进程，常常被称为交换进程(swapper)。该进程 并不执行 任何磁盘上的程序。〖CD2〗它是系统核的一部分，因此也被称为系统进程。进程 ID1通常是 ID1通常是 init进程，在自举过程结束时由系统核调用。该进程的程序文件在Unix的较早版本 中是/etc /init，在版新版本中是/sbin/init。此进程负责在系统核自举后起动一个Unix系 统。init 通常读与系统有关的初始化文件(/etc/rc*文件)，并将系统引导到一个状态(例如 多用户)。 init进程决不会终止。它是一个普通的用户进程(与交换进程不同，它不是一个在 系统核内 的系统进程)，但是它以超级用户特权运行。在本章稍后部分会说明init如何成为 所有孤儿 进程的父进程。 在某些Unix的虚存实现中，进程ID2是页精灵进程(pagedaemon)。此进程负责支持 虚存系统 的请页操作。 除了进程ID，每个进程还有一些其它标识符。下列函数返回这些标识符。 #include <sys/typesh> #include <unistdh> pid 迹茫模＊常病絫 getpid(voide;〓〓〖CD2〗调用进程的进程ID pid 迹茫模＊常病絫 getppid(void);〓〓〖CD2〗调用进程的父进程ID uid 迹茫模＊常病絫 getuid(void);〓〓〖CD2〗调用进程的实际用户ID uid 迹茫模＊常病絫 geteuid(void);〓返回：〓〓〖CD2〗调用进程的有效用户I D ID1通常是 init进程，在自举过程结束时由系统核调用。该进程的程序文件在Unix的较早版本 中是/etc /init，在版新版本中是/sbin/init。此进程负责在系统核自举后起动一个Unix系 统。init 通常读与系统有关的初始化文件(/etc/rc*文件)，并将系统引导到一个状态(例如 多用户)。 init进程决不会终止。它是一个普通的用户进程(与交换进程不同，它不是一个在 系统核内 的系统进程)，但是它以超级用户特权运行。在本章稍后部分会说明init如何成为 所有孤儿 进程的父进程。 在某些Unix的虚存实现中，进程ID2是页精灵进程(pagedaemon)。此进程负责支持 虚存系统 的请页操作。 除了进程ID，每个进程还有一些其它标识符。下列函数返回这些标识符。 #include <sys/typesh> #include <unistdh> pid 迹茫模＊常病絫 getpid(voide;〓〓〖CD2〗调用进程的进程ID pid 迹茫模＊常病絫 getppid(void);〓〓〖CD2〗调用进程的父进程ID uid 迹茫模＊常病絫 getuid(void);〓〓〖CD2〗调用进程的实际用户ID uid 迹茫模＊常病絫 geteuid(void);〓返回：〓〓〖CD2〗调用进程的有效用户I D D gid 迹茫模＊常病絫 getgid(void);〓〓〖CD2〗调用进程的实际组ID gid 迹茫模＊常病絫 getegid(void);〓〓〖CD2〗调用进程的有效组ID 注意，这些函数都没有出错返回，在下一章中讨论fork函数时，将进一步讨论父进 程ID。在 44节中已讨论了实际和有效用户及组ID。 83〓fork函数 一个现存进程调用fork函数是Unix核创建一个新进程的唯一方法。(这并不适用于 前节提及 的交换进程、init进程和页精灵进程。这些进程是由系统核作为自举过程的一部分 以特殊方 式创建的。) #include <sys/typesh> #include <unistdh> pid 迹茫模＊常病絫 fork(void); Returns:0 in child,process ID of child in parent,-1 on error〓返回：子进 程中为0 ，父进程中为子进程ID，出错为0 由fork创建的新进程被称为子进程。该函数被调用一次，但返回二次。两次返回的 区别是子 进程的返回值是0，而父进程的返回值则是新子进程的进程ID。将子进程ID返回给 父进程的 理由是：因为一个进程的子进程可以多于一个，所以没有一个函数使一个进程可以 程序81例示了Fork函数。如果执行此程序则得到： $ aout a write to stdout before fork pid=430,glob=7,var=89〓〓子进程的变量值改变了 pid=429,glob=6,var=88〓〓父进程的变量值没有改变 $ aout>tempout $ cat tempout a write to stdout before fork pid=432,glob=7,var=89 before fork pid=431,glob=6,var=88 一般，在fork之后里先进程先执行，还是子进程先执行是不确定的。这取决于系统 核所使用 的调度算法。如果要求文、字进程之间相互同步，则要求某种形式的进程间通信。 在程序8 1中，父进程体自己腔眠2秒钟，以此该子进程先执行。但并不保证2秒钟已经足 够，在8 8市说明竟学条件时，我们还够深及这一问题及其它类型的同步方法。在106节口 ，在fork之后我们将用信号体、父、子进程同步。 注意，程序81中fork与I/O函数之间的关系。回忆第三章中所述，Wrik函数是不 带缓存的。国灰在fork之间调用Wrir后，所以具数据写到标准输出上一次。但是， 程序81例示了Fork函数。如果执行此程序则得到： $ aout a write to stdout before fork pid=430,glob=7,var=89〓〓子进程的变量值改变了 pid=429,glob=6,var=88〓〓父进程的变量值没有改变 $ aout>tempout $ cat tempout a write to stdout before fork pid=432,glob=7,var=89 before fork pid=431,glob=6,var=88 一般，在fork之后里先进程先执行，还是子进程先执行是不确定的。这取决于系统 核所使用 的调度算法。如果要求文、字进程之间相互同步，则要求某种形式的进程间通信。 在程序8 1中，父进程体自己腔眠2秒钟，以此该子进程先执行。但并不保证2秒钟已经足 够，在8 8市说明竟学条件时，我们还够深及这一问题及其它类型的同步方法。在106节口 ，在fork之后我们将用信号体、父、子进程同步。 注意，程序81中fork与I/O函数之间的关系。回忆第三章中所述，Wrik函数是不 带缓存的。国灰在fork之间调用Wrir后，所以具数据写到标准输出上一次。但是， 图81〓fork之后父子、进程之间对打开文件的共享 这种共享文件的方式使父、子进程对同一文件使用了一个文件位移量。考虑下述情 况：一个 进程fork了一个子进程，然后等待子进程终止。假定，作为普通处理的一部分，父 、子进程 都向标准输出执行写操作。如果父进程使其标准输出重新定向(很可能是由shell实 现的)， 那么子进程写到该标准输出时，它将更新与父进程共享的该文件的位移量。在我们 所考虑的 例子中，当父进程等待子进程时，子进程写到标准输出；而在子进程终止后，父进 程也写到 标准输出上，并且知道其输出会添加在子进程所写数据之后。如果父、子进程不共 享同一文 件位移量，这种形式的交互作用就很难实现。 如果父、子进程写到同一描述符文件，但又没有任何形式的同步(例如使父进程等 待子进程) ，那么它们的输出就会相互混合(假定所用的描述符是在fork之前打开的)。虽然这 种情况是 可能发生的(见程序81)，但这并不是常用的操作方式。 有两种常见的在fork之后处理文件描述符的情况： 1父进程等待子进程完成。在这种情况下，父进程无需对其描述符作任何处理。 当子进程终止后，它曾进行过读、写操作的任一共享描述符的文件位移量也作了 相应更新。 相应更新。 2父、子进程各自执行不同的程序段。在这种情况下，在fork之后，父、子进程 各自关闭 它们不需使用的文件描述符，并且不干扰对方使用的文件描述符。这种方法是网络 服务进程 常常使用的。 除了打开文件之外，很多父进程的其它性质也由子进程继承： ·实际用户ID、实际组ID、有效用户ID、有效组ID ·添加组ID ·进程组ID ·对话期ID ·控制终端 ·设置-用户-ID标志和设置-组-ID标志 ·当前工作目录 ·根目录 ·文件方式创建屏蔽字 ·信号屏蔽和排列 ·对任一打开文件描述符的在执行时关闭标志 ·环境 ·连接的共享存储段 ·资源限制 父、子进程之间的区别是： · fork的返回值 · fork的返回值 ·进程ID ·不同的父进程ID ·子进程的tms 迹茫模＊常病絬time,tms 迹茫模＊常病絪time,tms 迹茫模＊常? 〗cutime 以及tms 迹茫模＊常病絬stime设置为0。 ·父进程设置的锁，子进程不继承 ·子进程的末决告警被清除 ·子进程的末决信号集设置为空集 其中很多特性至今尚末讨论过，我们将在以后几章中对它们进行说明。 使fork失败的两个主要原因是：(a)系统中已经有了太多的进程(通常意味着某个方 面出了 问题)，或者(b)该实际用户ID的进程总数超过了系统限制。回忆图27，其中CHI LD ＣＤ ＊常病組AX规定了每个实际用户ID在任一时刻可具有的最大进程数。 fork有两种用法： 1一个父进程希望复制自己，使父、子进程同时执行不同的代码段。这对网络服 务进程是 常见的〖CD2〗父进程等待委托者的服务请求。当这种请求到达时，父进程调用fo rk，使子 进程处理此请求。父进程则继续等待下一个服务请求。 2一个进程要执行一道不同的程序。这对shell是常见的情况。在这种情况下，子 进程在从 进程在从 fork返回后立即调用exec(我们将在89节说明exec)。 某些操作系统将2中的两个操作(fork之后执行exec)组合成一个，并称其为spawn。 Unix将这 两个操作分开，因为在很多场合需要单独使用fork，它后面并不跟随exec。另外， 将这两个 操作分开，使得子进程在fork和exec之间可以更改自己的属性。例如I/O重新定向 、用户ID 、信号排列等。在第十四章中有很多这方面的例子。 84〓vfork函数 vfork函数的调用序列和返回值与fork相同，但两者的语义不同。 vfork起源于较早的4BSD虚存版本。在Leffler et al ［1989］的57节中指出"虽 然它是 特 别有效率的，但是vfork的语义很奇特，通常认为它具有结构上的缺陷"。尽管如此 SVR4和4 3+BSD仍支持vfork。 某些系统具有头文件<vforkh>，当调用vfork时，应当包括该头文件。 vfork用于创建一个新进程，而该新进程的目的是exec一道新程序(为上节2中一样 )。程序1 5中的shell基本部分就是这种类型程序的一个例子。vfork与fork一样都创建一 个子进程 ，但是它并不将父进程的地址空间完全复制到子进程中，其设想是子进程会立即调 进程在从 fork返回后立即调用exec(我们将在89节说明exec)。 某些操作系统将2中的两个操作(fork之后执行exec)组合成一个，并称其为spawn。 Unix将这 两个操作分开，因为在很多场合需要单独使用fork，它后面并不跟随exec。另外， 将这两个 操作分开，使得子进程在fork和exec之间可以更改自己的属性。例如I/O重新定向 、用户ID 、信号排列等。在第十四章中有很多这方面的例子。 84〓vfork函数 vfork函数的调用序列和返回值与fork相同，但两者的语义不同。 vfork起源于较早的4BSD虚存版本。在Leffler et al ［1989］的57节中指出"虽 然它是 特 别有效率的，但是vfork的语义很奇特，通常认为它具有结构上的缺陷"。尽管如此 SVR4和4 3+BSD仍支持vfork。 某些系统具有头文件<vforkh>，当调用vfork时，应当包括该头文件。 vfork用于创建一个新进程，而该新进程的目的是exec一道新程序(为上节2中一样 )。程序1 5中的shell基本部分就是这种类型程序的一个例子。vfork与fork一样都创建一 个子进程 ，但是它并不将父进程的地址空间完全复制到子进程中，其设想是子进程会立即调 父进程的 地址空间中运行，所以这并不令人鹜讶。但是其作用的确与fork不同。 注意，在程序82中，调用了 迹茫模＊常病絜xit而不是exit。正如85节所述， 迹茫模? ２〗exit并不执行标准I/O缓存的刷新操作。如果用exit而不是 迹茫模＊常病? exit，则 该程序的输出是： $ aout before vfork 从中可见，父进程printf的输出消失了。其原因是子进程调用了exit，它刷新开关 闭了所有 标准I/O流。这包括标准输出。虽然这是由子进程执行的，但却是在父进程的地址 空间中进 行的，所以所有受到影响的标准I/O FILE对象都是在父进程中。当父进程调用pri ntf时，标 准输出已被关闭了，于是printf返回-1。 Leffler et al［１９８９］的57节中包含了fork和vfork实现方面的更多信息 。练习8 1和82则继续了对vfork的讨论。 85〓exit函数 如同在73节中所述，进程有三种正常终止法，有两种异常终止法。 1正常终止 (a)在main函数内执行return语句。如在73节中所述，这等效于调用exit。 (a)在main函数内执行return语句。如在73节中所述，这等效于调用exit。 (b)调用exit函数。此函数由ANSIC定义，其操作包括了调用各终止处理程序(终止 处理程序 是在调用atexit函数时登录的)，然后关闭所有标准I/O流等。因为ANSIC并不处理 文件描述 符、多进程(父、子进程)以及作业控制，所以这一定义对Unix系统而言是不完整的 。 (c)调用-exit系统调用函数。此函数由exit调用，它处理Unix特定的细节。-exit 是由POSIX 1说明的。 2异常终止： (a)调用abort。它产业SIGABRT信号，所以是下一种异常终止的一种特例。 (b)当进程接收到某个信号时。(第十章将较详细地说明信号)。进程本身(例如调用 abort函 数)、其它进程和系统核都能产生传送到某一进程的信号。例如，进程越出其地址 空间访问 存储单元，或者除以0，系统核就会为该进程产生相应的信号。 不管进程是如何终止的，最后都会执行系统核中的同一段代码。这段代码为相应进 程关闭所 有打开描述符，释放它所使用的存储器等等。 对上述任何一种终止情形，我们都希望终止进程能够通知其父进程它是如何终止的 。对于ex it和-exit，这是依靠传递给空们的退出状态参数来实现的。在异常终止情况，系 it和-exit，这是依靠传递给空们的退出状态参数来实现的。在异常终止情况，系 统核(不是 进程本身)产生一个指示其异常终止原因的终止状态。在任一种情况下，该终止进 程的父进 程都能用wait或waitpid函数(在下一节说明)取得其终止状态。 注意，我们在这里使用了"退出状态"(它是传向exit或-exit的参数，或main的返回 值)和 "终止状态"两个术语，以表示有所区别。在最后调用-exit时，系统核将其退出状 态转换 成终止状态(请回忆图71)。图82说明了父进程检查子进程的终止状态的不同方 法。如果 子进程正常终止，则父进程可以获得子进程的退出状态。 在说明fcrk函数时，一定是一个父进程生成一个子进程。上面又说明了子进程将其 终止状态 返回给父进程。但是如何父进程在子进程之前终止，则将如何呢?其回答是对于其 父进程已 经终止的所有进程，它们的父进程都改变为init进程。我们称这些进程由init进程 领养。其 操作过程大致是：在一个进程终止时，系统核逐个检查所有活动进程，以判断它是 否是正要 终止的进程的子进程，如果是，则该进程的父进程ID就更改为1(init进程的ID)。 这种处理 方法保证了每个进程有一个父进程。 方法保证了每个进程有一个父进程。 另一个我们关心的情况是如果子进程在父进程之前终止，那么父进程又如何能在作 相应检查 时得到子进程的终止状态呢?对此问题的回答是系统核为每个终止子进程保存了一 定量的信 息，所以当终止进程的父进程调用wait或waitpid时，可以得到有关信息。这种信 息至少包 括进程ID、该进程的终止状态、以反该进程使用的CPU时间总量。系统核可以释放 终止进程 所使用的所有存储器，关闭其所有打开文件。在Unix术语中，一个已经终止，但是 其父进程 尚末对其进行善后处理(获取终止子进程的有关信息、释放它仍占用的资源)的进程 被称为僵 死进程。PS(1)命令将僵死进程的状态打印为Z。如果编写一个长期运行的程序，它 fork了很 多子进程，那么除非父进程等待取得子进程的终止状态，否则这些子进程就会变成 僵死进程 。 系统V提供了一种避免僵死进程的非标准化方法，这将在107中介绍。 最后一个要考虑的问题是：一个由init进程领养的进程终止时会发生什么?它会不 会变成一 个僵死进程?对此问题的回答是"否"，因为init被编写成只要有一个子进程终止， init就 方法保证了每个进程有一个父进程。 另一个我们关心的情况是如果子进程在父进程之前终止，那么父进程又如何能在作 相应检查 时得到子进程的终止状态呢?对此问题的回答是系统核为每个终止子进程保存了一 定量的信 息，所以当终止进程的父进程调用wait或waitpid时，可以得到有关信息。这种信 息至少包 括进程ID、该进程的终止状态、以反该进程使用的CPU时间总量。系统核可以释放 终止进程 所使用的所有存储器，关闭其所有打开文件。在Unix术语中，一个已经终止，但是 其父进程 尚末对其进行善后处理(获取终止子进程的有关信息、释放它仍占用的资源)的进程 被称为僵 死进程。PS(1)命令将僵死进程的状态打印为Z。如果编写一个长期运行的程序，它 fork了很 多子进程，那么除非父进程等待取得子进程的终止状态，否则这些子进程就会变成 僵死进程 。 系统V提供了一种避免僵死进程的非标准化方法，这将在107中介绍。 最后一个要考虑的问题是：一个由init进程领养的进程终止时会发生什么?它会不 会变成一 个僵死进程?对此问题的回答是"否"，因为init被编写成只要有一个子进程终止， init就 init就 会调用一个wait函数取得其终止状态。这样也就防止了在系统中有很多僵死进程。 当提及" 一个init的子进程"时，这指的是init直接产生的进程(例如，将在92节说明的g etty进程 )，或者是其父进程已终止，由init收养的进程。 86〓wait和waitpid函数 当一个进程正常或异常终止时，系统核就向其父进程发送SIGCHLD信号。因为子进 程终止是 个异步文件(这可以在父进程运行的任何时候发生)，所以这种信号也是系统核向父 进程发的 异步通知。父进程可以忽略该信号，或者提供一个该信号发生时即被调用执行的函 数(信号 处理程序)。对于这种信号的系统默认动作是忽略它。在第十章将说明这些选择项 。现在需 要知道的是调用wait或waitpid的进程可能会： ·阻塞(如果其所有子进程都还在运行)，或者 ·带子进程的终止状态立即返回(如果一个子进程已终止，正等待父进程存取其终 止状态)， 或者 ·出错立即返回(如果它没有任何子进程)。 如果进程由于接收到SIGCHLD信号而调用wait，则可期望wait会立即返回。但是如 果在一个 果在一个 任意时刻调用wait，则进程可能会阻塞。 #include <sys/typesh> #include <sys/waith> pid 迹茫模＊常病絫 wait(int *statloc); pid 迹茫模＊常病絫 waitpid(pid 迹茫模＊常病絫 pid,int statloc, int op tions); Both return:process ID if OK,0(see later),or -1 on error〓两个函数返回： 若成功为 进程ID，出错为-1 这两个函数的区别是： ·在一个子进程终止前，wait使其调用者阻塞，而waitpid有一选择项，它可使用 调用者不 阻塞。 ·waitpid并不等待第一个终止的子进程〖CD2〗它有若干个选择项，可以控制它所 等待的进 程。 如果一个子进程已经终止，是一个僵死进程，则wait立即返回并取得该子进程的状 态，否则 wait使其调用者阻塞直到一个子进程终止。如调用者阻塞而且它有多个子进程，则 在其一个 子进程终止时，wait就立即返回。因为wait返回终止子进程的进程ID，所以它总能 子进程终止时，wait就立即返回。因为wait返回终止子进程的进程ID，所以它总能 了解是那 一个子进程终止了。 这两个函数的参数staloc是一个整型指针。如果staloc子是一个空指针，则终止进 程的终止 状态就存放在它所指向的单元内。如果不关心终止状态，则可将该参数指定为空指 针。 依据传统，这两个函数返回的整型状态字是由实现定义的。其中某些位表示退出状 态(正常 返回)，其它位则指示信号编号(异常返回)，有一位指示是否产生了一个core文件 等等。POS IX1规定终止状态用定义在<sys/waith>中的各个宏来查看。有三个互斥的宏可 用来取得 进程终止的原因，它们的名字都以WIF开始。基于这三个宏中哪一个值是真，就可 选用其它 宏来取得终止状态，信号编号等。这些都示于图82。在89节中讨论作业控制时 ，将说明 如何停止一个进程。 P198 图82〓检查wait和waitpid所返回的终止状态的宏 实例 程序83中的函数pr-exit使用图82中的宏以打印进程的终止状态。在本章的很 多程序中 程不是所期望的，则将该进程ID和终止状态保存起来，然后再次调用wait。反复这 样做直到 所期望的进程终止。下一次又想等待一个特定进程时，先查看已终止的进程表，若 其中已有 要等待的进程，则取有关信息，否则调用wait。其实，我们需要的是等待一个特定 进程的函 数。POSIX1定义了waitpid函数以提供这种功能(以及其它一些功能)。 waitpid函数是新由POSIX1定义的。SVR4和43+BSD都提供此函数，但早期的系 统V和43 BSD并不提供此函数。 P200 图83〓waitpid的选择项常数 对于waitpid的pid参数的解释与其值有关： pid==-1〓等待任一子进程。于是在这一功能方面waitpid与wait等效。 pid>0〓等待其进程ID与pid相等的子进程。 pid==0〓等待其组ID等于调用进程的组ID的任一子进程。 pid<-1〓等待其组ID等于pid的绝对值的任一子进程。 (在94节说明进程组)。waitpid返回该终止子进程的进程ID，而该子进程的终止 状态则通 过statloc返回。对于wait，其唯一的出错是调用进程没有子进程。(在此函数调用 由一个信 号中断时，也可能返回另一种出错。第十章将对此进程讨论。)但是对于waitpid， 如果指定 如果指定 的进程或进程组不存在，或者调用进程没有子进程都能出错。 options参数使我们能进一步控制waitpid的操作。此参数或者是0，或者是图83 中常数的 按位或。 SVR4支持两个附加的非标准的options常数。WNOWAIT使系统将其终止状态已由wai tpid返回 的进程保持在等待状态，于是该进程就可被再次等待。对于WCONTINUED，返回由p id指定的 某一子进程的状态，该子进程已被继续，其状态尚末报告过。 waitpid函数提供了wait函数没有提供的三个功能： 1 waitpid等待一个特定的进程(而wait则返回任一终止子进程的状态)。在讨论 popen函数 时会再说明这一功能。 2 waitpid提供了一个wait的非阻塞版本。有时希望取得一个子进程的状态，但 不想阻塞 。 3 waitpiol支持作业控制(以WUNTRACED选择项)。 实例 回忆一下85节中有关僵死进程的讨论。如果一个进程要fork一个子进程，但不要 求它等待 子进程终止，也不希望子进程处于僵死状态直到父进程终止，实现这一要求的决巧 是调用fo 是调用fo rk两次。程序85实现了这一点。 在第二个子进程中调用sleep以保证在打印父进程ID时第一个子进程已终止。在fo rk之后， 父、子进程都可继续执行〖CD2〗我们无法予知那一个会先执行。如果不使第二个 子进程睡 眠，则在fork之后，它可能比其父进程先执行，于是它打印的父进程ID会是它的父 进程，而 不是init进程(进程ID1)。 P202 程序85〓fork两次以避免僵死进程 执行程序85得到： $ aout $ second child,parent pid=1 注意，当原先的进程(也就是exec本程序的进程)终止时，shell打印其指示符，这 在第二个 子进程打印其父进程ID之前。 87〓wait3和wait4函数 43+BSD提供了两个附加函数wait3和wait4。这两个函数提供的功能比POSIX1函 数wait和 waitpid所提供的分别要多一个，它与附加参数rusage有关。该参数要求系统核返 回由终止 回由终止 进程及其所有子进程使用的资源摘要。 #include <sys/typesh> #include <sys/waith> #include <sys/timeh> #include <sys/resourceh> pid 迹茫模＊常病絫 wait3(int statloc,int options,struct rusage *rusae) ; pid 迹茫模＊常病絫 wait4(pid 迹茫模＊常病絫 pid,int *statloc,in t optio ns,struct rusage *rusage); Both return:process ID if OK,0,or -1 on error〓两个函数返回：若成功为进 程ID，出 错为-1 SVR4在其BSD兼容库中也提供了wait3函数。 资源信息包括用户CPU时间总量，系统CPU时间总量，缺页次数，接收到信号的次数 等。有关 细节请参阅getrusage(2)手册页。这些资源信息只包括终止子进程，并不包括处于 停止状态 的子进程。(这种资源信息与711节中所述的资源限制不同。)图84中列出了各 个wait函 数所支持的不同的参数。 数所支持的不同的参数。 P203 图84〓在不同系统上各个wait函数所支持的参数 88〓竟态条件 从本书的目的出发，当多个进程都企图对共享数据进行某种处理，而最后的结果又 取决于进 程运行的顺序时，则我们认为这发生了竟态条件。如果在fork之后的某种逻辑显式 或隐式地 依赖于在fork之后是父进程先运行还是子进程先运行，那么fork函数就会是竟态条 件活跃的 孳生地。通常，我们不能予料哪一个进程先运行。即使知道那一个进程先运行，那 么在该进 程开始运行后，所发生的事情也依赖于系统负载以及系统核的调度算法。 在程序85中，当第二个子进程打印其父进程ID时，我们看到了一个潜在的竟态条 件。如果 第二个子进程在第一个子进程之前运行，则其父进程将会是第一个子进程。但是， 如果第一 个子进程先运行，并有足够的时间到达并执行exit，则第二个子进程的父进程就是 init。即 使在程序中调用sleep，这也不保证什么。如果系统负担很重，那么在第二个子进 程从sleep 返回时，可能第一个子进程还没有得到机会运行。这种形式的问题很难排除，因为 在大部分 数所支持的不同的参数。 P203 图84〓在不同系统上各个wait函数所支持的参数 88〓竟态条件 从本书的目的出发，当多个进程都企图对共享数据进行某种处理，而最后的结果又 取决于进 程运行的顺序时，则我们认为这发生了竟态条件。如果在fork之后的某种逻辑显式 或隐式地 依赖于在fork之后是父进程先运行还是子进程先运行，那么fork函数就会是竟态条 件活跃的 孳生地。通常，我们不能予料哪一个进程先运行。即使知道那一个进程先运行，那 么在该进 程开始运行后，所发生的事情也依赖于系统负载以及系统核的调度算法。 在程序85中，当第二个子进程打印其父进程ID时，我们看到了一个潜在的竟态条 件。如果 第二个子进程在第一个子进程之前运行，则其父进程将会是第一个子进程。但是， 如果第一 个子进程先运行，并有足够的时间到达并执行exit，则第二个子进程的父进程就是 init。即 使在程序中调用sleep，这也不保证什么。如果系统负担很重，那么在第二个子进 程从sleep 返回时，可能第一个子进程还没有得到机会运行。这种形式的问题很难排除，因为 在大部分 在大部分 时间，这种问题并不出现。 如果一个进程希望等待一个子进程终止，则它必须调用wait函数。如果一个进程要 等待其父 进程终止(如程序85中一样)，则可使用下列形式的循环： while(getppid() !=1) sleep(1); 这种形式循环(称为定期询问)的问题是它浪费了CPU时间，因为调用者每隔1秒都被 唤醒，然 后进行条件测试。 为了避免竟态条件和定期询问，在多个进程之间需要有某种形式的信号机制。在U nix中可以 使用信号机制，在1016节将说明它的一种用法。各种形式的进程间通信(IPC)也 可使用， 在第十四、十五章将对此进行讨论。 在父、子进程关系中，常常有下述景况。在fork之后，父、子进程都有一些子情要 做。例如 ，父进程可能以子进程ID更新日志文件中的一个记录，而子进程则可能要为父进程 创建一个 文件。在这一例子中，我们要求每个进程在执行完它的一套初始化操作后要通知对 方，并且 在继续运行之前，要等待另一方完成其初始化操作。这种景况可以描述如下： #include "ourhdrh" #include "ourhdrh" TELL 迹茫模＊常病絎AIT(); /* set things up for TELL 迹茫模＊常病絰xx & WAIT〖 茫模＊常病絰xx */ if((pid=fork())<0) err 迹茫模＊常病絪ys("fork error"); else if (pid==0){〓〓/* 子进程 ／ 子进程执行所需的各操作 */ TELL 迹茫模＊常病絇ARENT(getppid());〓／ tell parent we're done */通知 父进程已 执行完毕 WAIT 迹茫模＊常病絇ARENT();〓/* and wait for parent */等待父进程 /* and the child continues on its way ··· */ 〓子进程继续运行 } /* 〓父进程执行所需的各操作 */ TELL 迹茫模＊常病紺HILD(pid);〓/* tell child we're done */ 通知子进程已 执行完毕 WAIT 迹茫模＊常病紺HILD();〓/* and wait for child */ 等待子进程 /* and the parent continues on its way ··· */ 父进程继续运行 exit(0); 假定在头文件ourbdrh中定义了各个需要使用的变量。五个例程TELL 迹茫模＊? ２〗WAIT ２〗WAIT 、TELL 迹茫模＊常病絇ARENT、TELL 迹茫模＊常病紺HILD、WAIT 迹茫模＊常病? PAREN以及 wAIT 迹茫模＊常病紺HILD可以是宏，也可以是函数。 在后面的一些章中会说明以不同的方法实现这些TELL和WAIT例程：1016节中说明 用信号的 一种实现，程序143中说明用流管道的一种实现。下面先看一个使用这五个例程 的实例。 实例 程序86输出两个字符串：一个由子进程输出，一个由父进程输出。因为输出依赖 于系统核 使进程运行的顺序及每个进程运行的时间长度，所以该程序包含了一个竟态条件。 P205 程序86〓具有竟态条件的程序 在程序中将标准输出设置为不带缓存的，于是每个字符输出都需调用一次write。 本例的目 的是使系统核能尽可能多次地在两个进程之间进行切换，以例示竟态条件。(如果 不这样做 ，可能也就决不会见到下面所示的输出。没有看到具有错误的输出并不意味着竟态 条件不存 在，这只是意味着在此特定的系统上未能见到它。)下面的实际输出说明该程序的 在，这只是意味着在此特定的系统上未能见到它。)下面的实际输出说明该程序的 运行结果 是会改变的。 $ aout output from child output from parent $ aout oouuttppuutt ffrroomm cphairledn t $ aout oouuttppuutt ffrroomm pcahrielndt $ aout ooutput from parent utput from child 修改程序86，使其使用TELL和WAIT函数，于是形成了程序87。在行首标以'+号 的行是 新增加的行。 P206 程序87〓修改程序86以避免竟态条件 运行此程序则能得到所予期的输出〖CD2〗两个进程的输出不再交叉混合。 程序87是使父进程先运行。如果将fork之后的行改变成： else if (pid==0) { charatatime("output from child＼n"); charatatime("output from child＼n"); TELL 迹茫模＊常病絇ARENT(getppid()); } else { WAIT 迹茫模＊常病紺HILD();〓〓/* child goes first */ 子进程先运行 charatatime("output from parent＼n"); } 则子进程先运行。练习83继续这一实例。 89〓exec函数 在83节曾提及用fork函数创建子进程后，子进程往往要调用一种exec函数以执行 另一道程 序。当一个进程调用一种exec函数时，该进程完全由新程序代换，而新程序则从其 main函数 开始执行。因为调用exec并不创建新进程，所以在其前后的进程ID并末改变。exe c只是用盘 上另一道新程序代换了当前进程的正文、数据、堆和栈段。 有六种不同的exec函数可供使用，它们常常被统称为exec函数。这些exec函数都是 Unix进程 控制原语。用fork可以创建新进程，用exec可以执行新的程序。exit函数和两个w ait函数处 理终止和等待终止。这些是我们需要的基本的进程控制原语。在后面各节中将使用 这些原语 构造另外一些如popen和system之类的函数。 #include <unistdh> #include <unistdh> int execl(const char *pathname,const char *arg0, /* (char *) 0 */) ; int execv(const char *pathname,char *const argv［］); int execle(const char *pathname,const char *arg0, /* (char *)0,char *const envp［］ */); int execve(const char *pathname,char *const argv［］,char *cons t envp ［］); int execlp(const char *filename,const char *arg0, /* (cha r *) 0 */ ); int execvp(const char *filename,char *const argv［］); All six return:-1 on error,no return on success 六个函数都返回：出错为-1，成功不返回 这些函数之间的第一个区别是前四个取路径名作为参数，后两个则取文件名作为参 数。当指 定文件名作为参数时： ·如果文件名中包含'/',则就将其视为路径名。 ·否则就按PATH环境变量，在有关目录中搜寻可执行文件。 PATH变量包含了一张目录表(称为路径前缀)，目录之间用冒号('：')分隔。例如下 列name #include <unistdh> int execl(const char *pathname,const char *arg0, /* (char *) 0 */) ; int execv(const char *pathname,char *const argv［］); int execle(const char *pathname,const char *arg0, /* (char *)0,char *const envp［］ */); int execve(const char *pathname,char *const argv［］,char *cons t envp ［］); int execlp(const char *filename,const char *arg0, /* (cha r *) 0 */ ); int execvp(const char *filename,char *const argv［］); All six return:-1 on error,no return on success 六个函数都返回：出错为-1，成功不返回 这些函数之间的第一个区别是前四个取路径名作为参数，后两个则取文件名作为参 数。当指 定文件名作为参数时： ·如果文件名中包含'/',则就将其视为路径名。 ·否则就按PATH环境变量，在有关目录中搜寻可执行文件。 PATH变量包含了一张目录表(称为路径前缀)，目录之间用冒号('：')分隔。例如下 列name 列name =value环境字符串： PATH=/bin:/usr/bin:/usr/local/bin:。 指定在四个目录中进行搜索。(一个零长前缀地表示当前目录。在value的开始处可 用：表示 它，在行中间则要用：：表示，在行尾以：表示它。) 有很多出于安全性方面的考虑，要求在搜索路径中决不要包括当前目录。请参见G arfinkel and Spafford［1991］。 如果execlp和execup这两个函数中的任一个使用路径前缀中的一个找到了一个可执 行文件， 但是该文件不是由连接编辑程序产生的机器可执行的代码文件，则就认为该文件是 一个shel l脚本，于是试着调用/bin/sh，并以该文件名作为shell的输入。 第二个区别与参数表的传递有关(l表示表(list)，v表示矢量(vector))。函数exe cl、execl p和execle要求将新程序的每个命令行参数都说明为一个单独的参数。这种参数表 以空指针 结尾。对于另外三个函数(execv,execvp和execve)，则应先构造一个指向各参数的 指针数组 ，然后将该数组地址作为这三个函数的参数。 在使用ANSIC原型之前，对execl,execle和execlp三个函数表示命令行参数的一般 方法是： 列name =value环境字符串： PATH=/bin:/usr/bin:/usr/local/bin:。 指定在四个目录中进行搜索。(一个零长前缀地表示当前目录。在value的开始处可 用：表示 它，在行中间则要用：：表示，在行尾以：表示它。) 有很多出于安全性方面的考虑，要求在搜索路径中决不要包括当前目录。请参见G arfinkel and Spafford［1991］。 如果execlp和execup这两个函数中的任一个使用路径前缀中的一个找到了一个可执 行文件， 但是该文件不是由连接编辑程序产生的机器可执行的代码文件，则就认为该文件是 一个shel l脚本，于是试着调用/bin/sh，并以该文件名作为shell的输入。 第二个区别与参数表的传递有关(l表示表(list)，v表示矢量(vector))。函数exe cl、execl p和execle要求将新程序的每个命令行参数都说明为一个单独的参数。这种参数表 以空指针 结尾。对于另外三个函数(execv,execvp和execve)，则应先构造一个指向各参数的 指针数组 ，然后将该数组地址作为这三个函数的参数。 在使用ANSIC原型之前，对execl,execle和execlp三个函数表示命令行参数的一般 方法是： ·添加组ID ·进程组ID ·对话期ID ·控制终端 ·闹钟尚余留的时间 ·当前工作目录 ·根目录 ·文件方式创建屏蔽字 ·文件锁 ·进程信号 帘为? ·末决信号 ·资源限制 ·tms-utime,tms-stime,tms-cutime以及tms-ustime值 对打开文件的处理与每个描述符的进程中每个在exec时关闭标志值有关。回忆图3 2以及3 13节中对PD-CLOEXEC的说明，打开描述符都有一个在exec时关闭标志。若此标志 设置，则 在执行exec时关闭该描述符，否则该描述符的打开除非特地用fcntl设置了该标志 ，否则系 统的默认操作是在exec后仍保持这种描述符打开。 POSIX1明确要求在exec时关闭打开目录流。(回忆42)节中所述的opendir函数 。)这通常 是由opendir函数实现的，它调用fcntl函数为对应于打开目录流的描述符设置在e 是由opendir函数实现的，它调用fcntl函数为对应于打开目录流的描述符设置在e xec时关闭 标志。 注意，在exec前后实际用户ID和实际组ID保持不变，而有效ID是否改变则取决于所 执行程序 的文件的设置用户ID位和设置组ID位是否设置。如果新程序的设置用户ID位已设置 ，则有效 用户ID变成程序文件属主的ID，否则有效用户ID不变。对组ID的处理方式与此相同 。 在很多Unix实现中，这六个函数中只有一个execve是系统核的系统调用。另外五个 只是库函 数，它们最终都要调用系统调用。这六个函数之间的关系示于图86中。在这种安 排中，库 函数execlp和execvp使用PATH环境变量查找第一个包含名为filename的可执行文件 的路径名 前缀。 P211 图86〓六个exec函数之间的关系 实际 程序88例示了exec函数。 P211 程序88〓exec函数的实例 在该程序中先调用execle，它要求一个路径名和一个特定的环境。下一个调用的是 在该程序中先调用execle，它要求一个路径名和一个特定的环境。下一个调用的是 execlp， 它用一个文件名，并将调用者的环境传送给新程序。execlp在这里能够工作的原因 是因为目 录/home/stevens/bin是当前路径前缀之一。注意，我们将第一个参数(在新程序中 的argv［ 0］)设置为路径名的文件名分量。某些shell将此参数设置为完全的路径名。 在程序88中要执行两次的程序echoall示于程序89中。这是一个普通程序，它 回送其所 有命令行参数及其全部环境表。 P212 程序89〓回送所有命令行参数和所有环境字符串 执行程序88时得到： $ aout argv［0］:echoall argv［1］:myarg1 argv［2］:MY ARG2 USER=unknown PATH=/tmp argv［0］:echoall $ argv［1］:only 1 arg USer=stevens USer=stevens HOME=/home/stevens LOGNAME=stevens 31 more lines that aren't shown其中31行没有显示 EDITOR=/usr/ucb/vi 注意，shell提示出现在第二个exec打印argv［0］和argv［1］之间。这是因为父 进程并不 等待该子进程结束。 810〓更改用户ID和组ID 可以用setuid函数设置实际用户ID和有效用户ID。与此类似，可以用setgid函数设 置实际组 ID和有效组ID。 #include <sys/typesh> #include <unistdh> int setuid(uid 迹茫模＊常病絫 uid); int setgid(gid 迹茫模＊常病絫 gid); Both return:0 if OK,-1 on error两个函数返回：若成功为0，出错为-1 关于谁能更改ID有若干规则。现在先考虑有关改变用户ID的规则(在这里关于用户 ID所说明 的一切都适用于组ID)。 1若进程具有超级用户特权，则setuid函数将实际用户ID，有效用户ID，以前保 存的设置 用户ID设置为uid。 用户ID设置为uid。 2若进程没有超级用户特权，但是uid等于实际用户ID或保存的设置用户ID，则s etuid只将 有效用户ID设置为uid。不改变实际用户ID和保存的设置用户ID。 3如果上面两个条件都不满足，则errno设置为EPERM，并出错返回。 在这里假 摇迹茫模＊常病絇OSIX 迹茫模＊常病絊AVED 迹茫模＊常病絀DS为真。 如果没有 提供这种功能，则上面所说的关于保存的设置用户ID的部分都无效。 FIPS 151-1要求此功能。 SVR4支持 迹茫模＊常病絇OSIX 迹茫模＊常病絊AVED 迹茫模＊常病絀DS功能。 关于系统核所维护的三个用户ID，还要注意下列几点： 1只有超级用户进程可以更改实际用户ID。通常，实际用户ID是在用户登录时， 由login(1 )程序设置的，而且决不会改变它。因为login是一个超级用户进程，当它调用set uid时，设 置所有三个用户ID。 2仅当对程序文件设置了设置-用户-ID位时，exec函数再设置有效用户ID。如果 设置-用户 -ID位没有设置，则exec函数不会改变有效用户ID，而将其维持为原先值。任何时 候都可以 调用setuid，将有效用户ID设置为或者实际用户ID，或者保存的设置-用户-ID。自 然，不能 将有效用户ID设置为任一随机值。 将有效用户ID设置为任一随机值。 3保存的设置-用户-ID是由exec从有效用户ID复制的。在exec按文件用户ID设置 了有效用 户ID后，即进行这种复制，并将此副本保存起来。 图87摘要列出了改变这三个用户ID的不同方法。 P214 图87〓改变三个用户ID的不同方法 注意，用82节中所述的getuid和geteuid函数只能获得实际用户ID和有效用户ID 的当前值 。我们不能获得所保存的设置-用户-ID的当前值。 实例 为了说明保存的设置-用户-ID特征的用法，让我们先观察一个使用该特征的程序。 我们所观 察的是贝克莱tip(1)程序(系统V的cu(1)程序与此类似。)这两个程序都连接到一个 远程系统 ，或者是直接连接，或者是拨号一个调制解调器。当tip使用一个调制解调器时， 它必须通 过使用锁文件来独占使用它。此锁文件是与UUCP共享的，因为这两个程序可能在同 时要使用 同一调制解调器。将发生下列步骤： 1tip程序文件是由用户uucp拥有的，并且其设置-用户-ID位已设置。当exec此程 序时，则 关于用户ID得到下列结果： 关于用户ID得到下列结果： 实际用户ID＝我们的用户ID 有效用户ID＝UUCP 保存设置用户ID＝UUCP 2tip存取所要求的锁文件。这些锁文件是由名为UUCP的用户所拥有的，因为有效 用户ID是 UUCP，所以tip可以存取这些锁文件。 3tip执行setuid(getuid())。因为tip不是超级用户进程，所以这仅仅改变有效 用户ID。 此时得到： 实际用户ID＝我们的用户ID(未改变) 有效用户ID＝我们的用户ID(未改变) 保存设置用户ID＝UUCP(未改变) 现在，tip进程是以我们的用户ID作为其有效用户ID而运行的。这就意味着能存取 的只是我 们通常可以存取的，没有附加的存取权。 4当执行完我们所需的操作后，tip执行setuid(uucpuid)，其中uucpuid是用户u ucp的数值 用户ID(tip很可能在起动时调用geteuid，得到uucp的用户ID，然后将其保存起来 ，我们并 不认为tip会搜索口令字文件以得到这一数值用户ID。)因为setuid的参数等于保存 的设置- 用户-ID，所以这种调用是许可的(这就是为什么需要保存的设置-用户-ID的原因。 用户-ID，所以这种调用是许可的(这就是为什么需要保存的设置-用户-ID的原因。 )现在得 到： 实际用户ID=我们的用户ID(末改变) 有效用户ID=uucp 保存设置用户ID=uucp(末改变) 5tip现在可对其锁文件进行操作以释放它们，因为tip的有效用户ID是。 以这种方法使用保存的设置-用户-ID，在进程的开始和结束部分就可以使用由于程 序文件的 设置用户ID而得到的额外的优先权。但是，进程在其运行的大部分时间只具有普通 的许可权 。如果进程不能在其结束部分切换回保存的设置-用户-ID，那么就不得不在全部运 行时间都 保持额外的许可权(这可能会造成麻烦)。 让我们来看一看如果在tip运行时为我们生成一个shell进程(先fork，然后exec)将 发生什么 。因为实际用户ID和有效用户ID都是我们的普通用户ID(上面的第三步)，所以该s hell没有 额外的许可权。它不能存取tip运行时设置成uucp的保存的设置-用户-ID，因为该 shell的保 存的设置-用户-ID是由exec复制有效用户ID而得到的。所以在执行exec的子进程中 ，所有三 个用户ID都是我们的普通用户ID。如若程序是设置-用户-ID为root,那么我们关于 用户-ID，所以这种调用是许可的(这就是为什么需要保存的设置-用户-ID的原因。 )现在得 到： 实际用户ID=我们的用户ID(末改变) 有效用户ID=uucp 保存设置用户ID=uucp(末改变) 5tip现在可对其锁文件进行操作以释放它们，因为tip的有效用户ID是。 以这种方法使用保存的设置-用户-ID，在进程的开始和结束部分就可以使用由于程 序文件的 设置用户ID而得到的额外的优先权。但是，进程在其运行的大部分时间只具有普通 的许可权 。如果进程不能在其结束部分切换回保存的设置-用户-ID，那么就不得不在全部运 行时间都 保持额外的许可权(这可能会造成麻烦)。 让我们来看一看如果在tip运行时为我们生成一个shell进程(先fork，然后exec)将 发生什么 。因为实际用户ID和有效用户ID都是我们的普通用户ID(上面的第三步)，所以该s hell没有 额外的许可权。它不能存取tip运行时设置成uucp的保存的设置-用户-ID，因为该 shell的保 存的设置-用户-ID是由exec复制有效用户ID而得到的。所以在执行exec的子进程中 ，所有三 个用户ID都是我们的普通用户ID。如若程序是设置-用户-ID为root,那么我们关于 就允许一个非特权用户前、后交换这二个用户ID的值，而43BSD中的tip程序就是 用这种功 能编写的。但是要知道，当此版本生成shell进程时，它必须在exec之前，先将实 际用户ID 设置为普通用户ID。如果不这样做的话，那么实际用户ID就可能是uucp(由setreu id的交换 操作造成。)然后shell进程可能会调用setreuid交换两个用户ID值并取得uucp许可 权。作为 一个保护性的程序设计措施，tip将子进程的实际用户ID和有效用户ID都设置成普 通用户ID 。 seteuid和setegid函数 在对POIX1的建议更改中包含了两个函数seteuid和setegid。它们只更改有效用 户ID和有 效组ID。 #include <sys/typesh> #include <unistdh> int seteuid(uid 迹茫模＊常病絫 uid); int setegid(gid 迹茫模＊常病絫 gid); Both return:0 if OK,-1 on error〓两个函数返回：若成功为0，出错为-1 一个非特权用户可将其有效用户ID设置为其实际用户ID或其保存的设置-用户-ID。 对于一个 特权用户则可将有效用户ID设置为uid。(这区别于setuid函数，它更改三个用户I 特权用户则可将有效用户ID设置为uid。(这区别于setuid函数，它更改三个用户I D。)这一 建议更改也要求支持保存的设置-用户-ID。 SVR4和43+BSD都支持这两种函数。 图88〓摘要列出了本节所述的修改三个不同的用户ID的各个函数。 P217 图88〓设置不同的用户ID的各函数摘要 组ID 至此，在本章中所说明的一切都以类似方式适用于各个组ID。添加组ID不受setgi d函数的影 响。 811〓解释器文件 SVR4和43+BSD都支持解释器文件。这种文件是文本文件，其起始行的形式是： ＃！ pathname［optional-argument］ 在骛叹号和pathname之间的空格是可任选的。最常见的是以下列行开始： #！/bin/sh pathname通常是个绝对路径名，对它不进行什么特殊的处理(不使用PATH进行路径 搜索)。对 这种文件的识别是由系统核作为exec系统调用处理的一部分来完成的。系统核使调 用exec函 数的进程实际执行的文件并不是该解释器文件，而是在该解释器文件的第一行中p athname所 指定的文件。一定要将解释器文件(文本文件，它以#！开头)和解释器(由该解释器 指定的文件。一定要将解释器文件(文本文件，它以#！开头)和解释器(由该解释器 文件第一 行中的pathname指定)区分开来。 要了解，很多系统对解释器文件第一行有长度限止(32个字符)。这包括#！，path name，选 择参数以及空格数。 实例 让我们观察一个实例，从中了解当被执行的文件是个解释器文件时，系统核对exe c函数的参 数及该解释器文件第一行的可任选参数作何种处理。程序810调用execl执行一个 解释器文 件。 P218 程序810〓执行一个解释器文件的程序 下面先显示要被执行的该解释器文件(只有一行)的内容，接着是运行程序810的 结果。 $ cat /home/stevens/bin/testinterp #!/home/stevens/bin/echoarg foo $ aout argv［0］: /home/stevens/bin/echoarg argv［1］: foo argv［2］: /home/stevens/bin/testinterp argv［3］: myarg1 argv［3］: myarg1 argv［4］: MY ARG2 程序ecboarg(解释器)回送每一个命令行参数。(它就是程序72。)注意，当系统 核exec该 解释器(/home/stevens/bin/ecboarg)时，argv［0］是该解释器的路径名，argv［ 1］是解 释器 文件中的可任选择参数，其余参数是路径名(/bome/stevens/bin/testinterp)，以 及程序8 10中调用execl的第二和第三个参数(myarg1,和MY ARG2)。调用execl时的argv［ 1］和arg v［2］和argv［3］已向右移了两个位置。 注意，系统核取了execl中的路径名以代替第一个参数(testinterp)，因为一般路 径名包含 了较第一个参数更多的信息。 实例 在解释器路径名(pathname)后可跟随任选参数，它们常用于为支持-f任选项的程序 指定该任 选项。例如，可以以下列方式执行awk(1)程序： awk -f myfile 它告诉awk从文件myfile中读awk程序 在很多系统中，有awk的两个版本。awk常常被称为"老awk"，它是与version 7一起 分发的 分发的 原始版本。nawk(新awk)包含了很多增强功能，对应于在Aho,Kernighan和Weinber ger［1988 ］ 中说明的语言。此新版本提供了对命令行参数的存取，这是下面的例子所需的。S VR4提供了 两者，老的awk既可用awk也可用oawk调用，但是SVR4已说明在将来的版本中awk将 是nawk。P OSIX2章节中将新awk语句就称为awk，这正是在本书中所使用的。 在解释器文件中使用-f任选项，使我们可以写出： #！／bin/awk -f (在此解释器文件中后随awk程序) 例如，程序811是一个在/usr/local/bin/awkexample解释器文件中的程序。 P218 程序811〓在一个解释器文件中的awk程序。 如果路径前缀之一是/usr/local/bin，则可以下列方式执行程序811(假定我们已 打开了该 文件的执行位)： $ awkexample filel FILENAME2 f3 ARGV［0］=/bin/awk ARGV［1］=file1 ARGV［2］=FILENAME2 ARGV［3］=f3 ARGV［3］=f3 执行/bin/awk时，其命令行参数是： /bin/awk -f /usr/local/bin/awkexample file1 FILENAME2 f3 解释器文件的路径名(/usr/local/bin/awkexample)传送给解释器。因为不能期望 该解释器( 在本例中是/bin/awk)会使用PATH变量定位该解释器文件，所以只传春路径名中的 文件名是 不够的。当awk读解释器文件时，因为'＃'是awk的注释字符，所以在awk读解释器 文件时 ，它忽略第一行。 可以用下列命令验证上述命令行参数。 $ su〓〓成为超级用户 Password:〓输入超级用户口令 # mv/bin/awk /bin/awksave〓保存原先的程序 # cp /home/stevens/bin/echoarg /bin/awk〓暂时代换它 # suspend〓用作业控制挂起超级用户shell ［1］+Stopped〓〓su $ awkexample file1 FILENAME2 f3 argv［0］: /bin/awk argv［1］: -f argv［2］: /usr/local/bin/awkexample argv［3］: file1 argv［4］: FILENAME2 argv［4］: FILENAME2 argv［5］: f3 $ fg〓〓用作业控制恢复超级用户shell su # mv /bin/awksave /bin/awk〓恢复原先的程序 # exit〓终止超级用户shell 在此例子中，解释器的－f任选项是需要的。正如前述，它告诉awk在什么地方得到 awk程序 。如果在解释器文件中删除-f任选面，则其结果是： $ awkexample file1 FILENAME2 f3 /bin/awk:syntax error at source line 1 context if >>> /user/local <<< /bin/awkexample /bin/awk: bailing out at source line 1 因为在这种情况下命令行参数是： /bin/awk /usr/local/bin/awkexampel file1 FILENAME2 f3 于是awk企图将字符串/usr/local/bin/awkexample解释为一个awk程序。如果不能 向解释器 至少传递一个可任选参数(在本例中是-f)，那么这些解释器文件只有对shell才是 有用的。 是否一定需要解释器文件呢?那也不完全如此。但是它们确实使用户得到效率方面 的好处， 的好处， 其代价是系统核的额外开销(因为系统核需要识别解释器文件)。由于下述理由，解 释器文件 是有用的。 1某些程序是用某种语言写的脚本，这一事实可以隐藏起来。例如，为了执行程 序811， 只需使用下列命令行： awkexample optional-arguments 而并不需要知道该程序实际上是一个awk脚本，否则我们就要以下列方式执行该程 序： awk -f awkexample optional-arguments 2解释器脚本在效率方面也提供了好处。再考虑一下前面的例子。我们仍旧隐藏 该程序是 一个awk脚本的事实，但是将其放在一个shell脚本中： awk 'BEGIN { for(i=0;i<ARGC;i++) printf "ARGV［%d］=%s＼n",i,ARGVp［i］ exit }' $* 这种解决方法的问题是要求做更多的工作。首先，shell读此命令，然后试图exec lp此文件 名。因为shell脚本是一个可执行文件，但却不是机器可执行的，于是返回一个错 误；然后 误；然后 ，execlp就认为该文件是一个shell脚本(它实际上就是这种文件)。然后，exec / bin/sh， 并以该Shell脚本的路径名作为其参数。shell正确地解释执行我们的shell脚本， 但是为了 运行awk程序，它调用fork,exec和wait。用一个shell脚本代替解释器脚本有更多 的开销。 3解释器脚本使我们可以使用除/bin/sh以外的其它shell来编写shell脚本。当e xeclp找到 一个非机器可执行的可执行文件时，它总是调用/bin/sh来解释执行该文件。但是 用解释器 脚本，则可编写成： #!/bin/csh (在此解释器文件中后随C Shell脚本) 再一次，我们也可将此放在一个/bin/sh脚本中(然后由其调用C shell)，但是要有 更多的开 销。 如果三个shell和awk没有用'#'作为注释符，则我们上面说的都不会工作。 812〓System函数 在一个程序中执行一个命令字符串是方便的。例如，假定我们要将时间和日期放到 一个文件 中，则可使用69节说明的函数实现这一点。调用time得到当前日历时间，接着调 中，则可使用69节说明的函数实现这一点。调用time得到当前日历时间，接着调 用localt ime将日历时间变换为年、月、日、时、分、秒、周日形式，然后调用Strftime对 上面的结 果进行格式化处理，最后将结果写到文件中。但是用下面的system函数则更容易做 到这一点 。 system("date>file"); ANSI C定义了system函数，但是其操作是强烈依赖于系统的。 因为system不属于操作系统界面而是shell界面，所以POSIX1没有定义它，POSI X2则正 在对其进行标准化。下列说明与POSIX2标准的草案112相一致。 #include <stdlibh> int system(const char *cmdstring); Returns:(see below)返回：(见下) 如果cmdstring是一个空指针，则仅当命令处理程序可用时，system返回非0值，使 用这一特 征可以决定在一个给定的操作系统上是否支持system函数。在Unix中，system总是 可用的。 因为system在其实现中调用了fork、exec和waitpid，因此有三种返回值： 1如果fork失败或者waitpid返回除EINTR之外的出错，则system返回-1，而且er ro中设置 中，则可使用69节说明的函数实现这一点。调用time得到当前日历时间，接着调 用localt ime将日历时间变换为年、月、日、时、分、秒、周日形式，然后调用Strftime对 上面的结 果进行格式化处理，最后将结果写到文件中。但是用下面的system函数则更容易做 到这一点 。 system("date>file"); ANSI C定义了system函数，但是其操作是强烈依赖于系统的。 因为system不属于操作系统界面而是shell界面，所以POSIX1没有定义它，POSI X2则正 在对其进行标准化。下列说明与POSIX2标准的草案112相一致。 #include <stdlibh> int system(const char *cmdstring); Returns:(see below)返回：(见下) 如果cmdstring是一个空指针，则仅当命令处理程序可用时，system返回非0值，使 用这一特 征可以决定在一个给定的操作系统上是否支持system函数。在Unix中，system总是 可用的。 因为system在其实现中调用了fork、exec和waitpid，因此有三种返回值： 1如果fork失败或者waitpid返回除EINTR之外的出错，则system返回-1，而且er ro中设置 ro中设置 了错误类型。 2如果exec失败(表示不能执行shell)，则其返回值如同shell执行了exit(127)一 样。 3否则所有三个函数(fork,exec和waitpid)都成功，则system的返回值是shell的 终止状态 ，其格式是在waitpid中所说明的。 如果waitpid是一个捕捉到的信号中断，则system很多当前的实现都返回一个错误 (EINTR)， 要求在这种情况下system不返回一个错误已被加到POSIX2的最近草案中。(在10 5节中将 讨论被中断的系统调用。) 程序812是system函数的一种实现。它对信号没有进行处理。在1018节中将修 改此函数 使其进行信号处理。 Shell的-C任选项告诉shell程序取下一个命令行参数(在这里是cmdstring)作为命 令输入(而 不是从标准输入或从一个给定的文件中读命令)。Shell对以null字符终止的命令字 符串进行 语法分析，将它们分成分隔开的命令行参数。传递给shell的实际命令串可以包含 任一有效 的shell命令。例如，可以用<和>对输入和输出重新定向。 如果不使用shell执行此命令，而是试图由我们自己去执行它，那么这会是相当困 stevens ttyp1 〓Aug 29 05:56 stevens ttyp2 〓Aug 29 05:56 normal termination,exit status=44〓对于exit 程序813〓调用system函数 使用system而不是直接使用fork和exec的优点是：system进行了所需的各种出错处 理，以及 各种信号处理(在1018节中的下一个版本system函数中)。 在Unix的早期版本中，包括SVR32和43BSD，都没有waitpid函数，于是父进程 用下列形 式的语句等待子进程： while((lastpid=wait(& status)) !=pid && lastpid !=-1) ； 如果调用system的进程在调用它之前已经生成一个子进程(并exec一道程序)，则就 会引起问 题。因为上面的while语句一直循环执行，直到由system产生的子进程终止才停止 ，如果其 任一个不是用pid标识的子进程在此之前终止，则它们的进程ID和终止状态都被wh ile语句丢 弃。确实，由于wait不能等待一个指定的进程，POSIX1才为此及其它一些原因定 义了wait pid函数。如果不提供waitpid，对于popen和pclose函数也会发生同样的问题。 设置-用户-ID程序 如果在一个设置-用户-ID程序中调用system，那么发生什么呢?这是一个安全性方 如果在一个设置-用户-ID程序中调用system，那么发生什么呢?这是一个安全性方 面的漏洞 ，决不应当这样做。程序814是一个简单程序，它只是对其命令行参数调用syte m函数。 P225 程序814〓用system执行命令行参数 将此程序编译成可执行目标文件tsys。 程序815是另一个简单程序，它打印其实际和有效用户ID。 P225 程序815〓打印实际和有效用户ID 将此程序编译成可执行目标文件printuids运行这两个程序，得到下列结果： $ tsys printuids〓〓正常执行，无特权 real uid=224,effective uid=224 normal termination,exit status=0 $ su〓〓成为超级用户 Password:〓〓输入超级用户口令 # chown root tsys〓〓更改属主 # chmod u+s tsys〓〓增加设置用户-ID # ls -1 tsys〓〓检验文件许可权和属主 -rwsrwxr-x 1 root〓105737 Ang 18 11:21 tsys # exit〓〓终止超级用户shell $ tsys printuids $ tsys printuids real uid=224,effective uid=0〓〓oops,这是一个安全性空洞 normal termination,exit status=0 我们给予tsys程序的超级用户许可权在system中执行了fork和exec之后仍被保持下 来，也就 是说执行system中shell命令的进程也是有了超级用户许可权。 如果一个进程正以特殊的许可权(设置-用户-ID或设置-组-ID)运行，它又想生成另 一个进程 执行另一道程序，则它应当直接使用fork和exec，而且在fork之后，exec之前要改 回到普通 许可权。设置-用户-ID或设置-组-ID程序决不应调用system函数。 这种警告的一个理由是：system调用shell对命令字符串进行语法分析，而shell则 使用IFS 变量作为其输入字段分隔符。较早的shell版本在被调用时不将此变量恢复为普通 字符集。 这就允许一个不怀好意的用户在调用system之前设置IFS，造成system执行一个不 同的程序 。 813〓进程会计 很多Unix系统提供了一个任选项以进行进程会计事务处理。当取了这种任选项后， 每当进程 结束时系统核就写一个会计记录。典型的会计记录是32个字节长的二进制数据，包 括命令名 $ tsys printuids real uid=224,effective uid=0〓〓oops,这是一个安全性空洞 normal termination,exit status=0 我们给予tsys程序的超级用户许可权在system中执行了fork和exec之后仍被保持下 来，也就 是说执行system中shell命令的进程也是有了超级用户许可权。 如果一个进程正以特殊的许可权(设置-用户-ID或设置-组-ID)运行，它又想生成另 一个进程 执行另一道程序，则它应当直接使用fork和exec，而且在fork之后，exec之前要改 回到普通 许可权。设置-用户-ID或设置-组-ID程序决不应调用system函数。 这种警告的一个理由是：system调用shell对命令字符串进行语法分析，而shell则 使用IFS 变量作为其输入字段分隔符。较早的shell版本在被调用时不将此变量恢复为普通 字符集。 这就允许一个不怀好意的用户在调用system之前设置IFS，造成system执行一个不 同的程序 。 813〓进程会计 很多Unix系统提供了一个任选项以进行进程会计事务处理。当取了这种任选项后， 每当进程 结束时系统核就写一个会计记录。典型的会计记录是32个字节长的二进制数据，包 括命令名 struct acct { char〓ac 迹茫模＊常病絝lag; /*〓标志(见图89) char〓ac 迹茫模＊常病絪tat; /*〓终止状态(只是信号和core标志) 〓〓〓〓〓/*〓(BSD系统不提供) uid 迹茫模＊常病絫〓ac 迹茫模＊常病絬id;〓/*〓实际用户ID gid 迹茫模＊常病絫〓ac 迹茫模＊常病絞id;〓/*〓实际组ID dev 迹茫模＊常病絫〓ac 迹茫模＊常病絫ty;〓 〓控制终端 time 迹茫模＊常病絫〓ac 迹茫模＊常病絙time;〓 〓起始日历时间 comp 迹茫模＊常病絫〓ac 迹茫模＊常病絬time; 〓/*〓用户CPU时间(滴答) comp 迹茫模＊常病絫〓ac 迹茫模＊常病絪time;〓/*〓系统CPU时间(滴答) comp 迹茫模＊常病絫〓ac 迹茫模＊常病絜time;〓 〓经过的时间(滴答) comp 迹茫模＊常病絫〓ac 迹茫模＊常病絤em;〓/〓*平均使用的内存 comp 迹茫模＊常病絫〓ac 迹茫模＊常病絠o;〓/*〓读、写传输的字节数 comp 迹茫模＊常病絫〓ac 迹茫模＊常病絩w;〓/*〓块读或写 常? char ac-comm［B］; 〓／命令名：SVR4是 郏 ］，43+BSD是［１０ 荨常? }； 由于历史传统，贝克莱系统，包括43+BSD不提供ac-stat变量。 其中，ac-flag记录了进程执行期间的某些事件。这些事件如图89中所示。 P227 图89〓会计记录中的ac-flag值 图89〓会计记录中的ac-flag值 会计记录所需的各个数据(各CPU时间，传输的字符数等)都由系统核保存在进程表 中，并在 一个新进程被创建时置初值(例如fork之后在子进程中)。一个进程终止时写一个会 计记录。 这就意味着在会计文件中记录的顺序对应于进程终止的顺序，而不是它们起动的顺 序。为了 确定起动顺序，须要读全部会计文件，并按起动日历时间进行排序。这不是一种很 完善的方 法，因为日历时间的单位是秒(110节)，在一个给定的秒中可能起动了多个进程 。而墙上 时钟时间的单位是时钟滴答(通常，每秒滴答数在50～１００之间)。但是我们并不 知道进程 的终止时间，我们所知道的只是起动时间和终止顺序。这就意味着，即使墙上时间 比起动时 间要精确得多，但是我们仍不能按照会计文件中的数据重构各进程的精确起动顺序 。 会计记录对应于进程而不是程序。在fork之后，系统核为子进程初始化一个记录， 这不是在 一个新程序被执行时。虽然exec并不创建一个新的会计记录，但相应记录中的命令 名改变了 ，AFORK标志则被清除。这意味着，如果一个进程顺序exec了三道程序(A exec B, B exec C, B exec C, 最后C exit)，但只写一个会计记录。在该记录中的命令名对应于程序C，但CPU时 间是程序A 、B、C之和。 实例 为了得到某些会计数据以便查看，运行程序816，它调用fork四次。每个子进程 做不同的 事情，然后终止。此程序所做的基本工作示于图810中。 程序817则从会计记录中选择出一些字段并打印出来。 P228 程序816〓产生会计数据的程序 P229 图810〓会计处理实例的进程结构 然后，执行下列操作步骤： 1变成为超级用户，用acction命令起动会计事务处理。注意，当此命令结束时， 会计事务 处理已经起动，因此在会计文件中的第一个记录应来自这一命令。 2运行程序816。这会加五个记录到会计文件中(父进程1个，四个子进程各一个 )。在第 二个子进程中，execl并不创建一个新进程，所以对第二个进程只有一个会计记录 。 3变成为超级用户，停止会计事务处理。因为在acction命令终止时已停止处理会 计事务， 计事务， 所以不会在会计文件中增加一个记录。 4运行程序817，从打印文件中选出字段并打印之。 步骤4的输出如下面所示。在每一行以斜体字对进程加了说明，以便后面讨论。 accton〓e 〓７，chars〓６４，stat=〓０：〓Ｓ dd〓e=〓37，chars=221888,stat〓０：〓〓第2子进程 aout〓e=〓１２８，chars＝〓０，stat=〓０：〓〓父进程 aout〓e=〓274，chars=〓0，stat=134:F 摹。亍?子进程 aout〓e=〓360,chars=〓0，stat=〓９：Ｆ〓〓Ｘ〓第4子进程 aout〓e＝〓484,chars=〓０，stat=〓０：Ｆ〓〓第3子进程 P230 程序817〓打印从系统会计文件中选出的字段 墙上日历时间值的单位是CLK 迹茫模＊常病絋CK。从图26中可见，本系统的值是 60。例如 ，在父进程中 的sleep(2)对应于墙上日历时间128个时钟滴答。对于第一个子进程，sleep(4)变 成274时钟 滴答。注意，一个进程睡眠的时间总量并不精确(在第十章中将返回到sleep函数。 )调用for k和exit也要一些时间。 注意，ac-stat并不是进程的真正终止状态。它只是86节中讨论的终止状态的一 部分。如 计事务， 所以不会在会计文件中增加一个记录。 4运行程序817，从打印文件中选出字段并打印之。 步骤4的输出如下面所示。在每一行以斜体字对进程加了说明，以便后面讨论。 accton〓e 〓７，chars〓６４，stat=〓０：〓Ｓ dd〓e=〓37，chars=221888,stat〓０：〓〓第2子进程 aout〓e=〓１２８，chars＝〓０，stat=〓０：〓〓父进程 aout〓e=〓274，chars=〓0，stat=134:F 摹。亍?子进程 aout〓e=〓360,chars=〓0，stat=〓９：Ｆ〓〓Ｘ〓第4子进程 aout〓e＝〓484,chars=〓０，stat=〓０：Ｆ〓〓第3子进程 P230 程序817〓打印从系统会计文件中选出的字段 墙上日历时间值的单位是CLK 迹茫模＊常病絋CK。从图26中可见，本系统的值是 60。例如 ，在父进程中 的sleep(2)对应于墙上日历时间128个时钟滴答。对于第一个子进程，sleep(4)变 成274时钟 滴答。注意，一个进程睡眠的时间总量并不精确(在第十章中将返回到sleep函数。 )调用for k和exit也要一些时间。 注意，ac-stat并不是进程的真正终止状态。它只是86节中讨论的终止状态的一 部分。如 部分。如 果进程异常终止，则在此字节中的信息只是core标志位(一般是最高位)以及信号编 号数(一 般是低7位)。如果进程正常终止，则从会计文件不能得到进程的退出(exit)状态。 对于第一 个进程，此值是128+6。128是core标志位，6是此系统上信号SIGBART的值(它是由 调用abort 产生的)。第四个子进程的值是9，它对应于SIGKILL的值。从会计文件的数据中不 能得到父 进程在exit时所用的参数值是2，三个子进程exit时所用的参数值是0。 dd进程复制到第二个子进程中的文件/boot的长度是110，888 byte。而I/O字符数 是此值的 二倍，因为读了110，888byta，然后又写了110，888byte。即使输出到null设备， 仍对I/O 字符数进行计算。 ac-flag值与我们所予料的相同。除调用了execl的第二个子进程以外，其它子进程 都设置了 F标志。父进程没有设置F标志，其原因是交互式shell曾调用过fork生成父进程， 然后调用e xec aout文件。调用了abort的第一个子进程的core转储标志(D)打开。因为abo rt产生信 号 SIGABRT以产生core转储。该进程的X标志也打开，因为它是由信号终止的。第四个 SIGABRT以产生core转储。该进程的X标志也打开，因为它是由信号终止的。第四个 子进程的 X标志也打开，但是SIGKILL信号并不产生core转储，它只是终止该进程。 最后要说明的是：第一个子进程的I/O字符数为O，但是该进程产生了一个core文件 。其原因 是写core文件所需的I/O并不由该进程负担。 814〓用户标识 任一进程都可以得到其实际和有效用户ID及组ID。但是有时希望找到运行该程序的 用户的登 录名。我们可以调用getpwuid(getuid())，但是如果一个用户有多个登录名，这些 登录名又 对应着同一个用户ID，这又将如何呢?(一个人在口令字文件中可以有多个记录项， 它们的用 户ID相同，但登录shell则不同)。系统通常保存用户的登录名(67节)，用getlo gin函数可 以存取此登录名。 #include <unistdh> char *getlogin(void); Returns:pointer to string giving login name if OK,NULL on error返回： 若成功为 指向登录名字符串的指针，出错为NULL。 如果调用此函数的进程没有连接到用户登录时所用的终端，则本函数会失败。我们 通常称这 数以获得它自己及终止子进程的上述值。 #include <sys/timesh> clock 迹茫模＊常病絫 times(struct tms *buf)); Returns:elapsed wall clock time in clock ticks if OK,-1 on error 返回：若成功为经过的墙上时钟时间(单位：滴答)，出错为-1 此函数填写由buf指向的tms结构，该结构定义是： struct tms{ clock 迹茫模＊常病絫 tms 迹茫模＊常病絬time; /* user CPU time */〓用户C PU时间 clock 迹茫模＊常病絫 tms 迹茫模＊常病絪time; /* system CPU time */ 系统 CPU时间 clock 迹茫模＊常病絫 tms 迹茫模＊常病絚utime; /* user CPU time,terminat ed childr en */各终止子进程的用户CPU时间 clock 迹茫模＊常病絫 tms 迹茫模＊常病絚stime; /* system CPU time,termin ated chil dren */各终止子进程的系统CPU时间 注意，此结构没有包含墙上时钟时间。作为代替times此函数以函数值返回墙上时 钟时间。 此值是相对于过去的某一时刻度量的，所以不能用其绝对值而必须使用其相对值。 例如，调 用times，保存其返回值。在以后某个时间再次调用times，从新返回的值中减去以 前返回的 前返回的 值。此差值就是墙上时钟时间。(一个长期运行的进程可能其墙上时钟时间会溢出 ，当然这 种可能性极小。 结构中两个针对子进程的字段包含了此进程已等待到的各子进程的值。 所有由此函数返回的CLOCK-t值都用-SC-CLK-TCK(由sysconf函数返回的每秒时钟滴 答数，见 254节)换成秒数。 贝克莱类系统，包括43BSD继承了Version 7的times版本，它不返回墙上时钟时 间。这一 老版本如果执行成功返回0，如失败则返回-1。43+BSD支持POSIX1版本。 43+BSD和SVR4(在BSD兼容库中)提供了getrusage(2)函数，此函数返回CPU时间， 以及指示 资源使用情况的另外十四个值。 实例 程序818将每个命令行参数作为Shell命令串执行，对每个命令计时，并打印从tms 结构取得 的值。按下列方式运行此程序，得到： $ aout "sleep 5" "date" command: sleep 5 real:〓〓525 user:〓〓000 sys:〓〓000 sys:〓〓000 child user:〓〓002 child sys:〓〓013 normal termination,exit status=0 command:date Sun Aug 18 09:25:38 MST 1991 real :〓〓027 user:〓〓０００ sys:〓〓〓000 child user:〓〓005 child sys:〓〓010 normal termination,exit status=0 在两个实例中，在child user和child sys行中显示的时间是执行shell和命令的子 进程所使用的CPU时间。 程序818〓时间以及执行命令行参数 让我们再运行110节中的例子： P235 如同所期望的那样，所有三个值(实际时间和子进程CPU时间)都与110高中的值相 近。 816〓摘要 对在Unix环境中的高级程序设计而言，完整地了解Unix的进程控制是非常重要的。 其中必须熟练掌握的只有几个〖CD2〗fork、exec族、-exit、wait和waitpid。很多 应用程序都使用这些原语。fork原语也给了我们一个了解竟态条件的机会。 进程所使用的CPU时间。 在本章中说明了system函数和进程会计，与此同时也使我们可以看到这些进程控制 函数的应用情况。本章还说明了exec函数的另一种变体；解释器文件及它们工作的 方式。对各种不同的用户ID和组ID(实际，保存的)的理解和编写安全的设置用户ID程序 是至 ? 重要的。 在下一章我们在了解进程和子进程的基础上，进一步说明进程和其它进程的关系〖 CD2〗对话期和作业控制。在第十章我们将说明信号机制以此结束对进程的讨论。 -- ※ 来源:·BBS 水木清华站 smth.org·[FROM: 162.105.8.213] -- ☆ 来源:．BBS 荔园晨风站 bbs.szu.edu.cn．[FROM: bbs@192.168.28.23] |
| [返回保留区目录] |
 |
|
|
