- 论坛徽章:
- 2
|
|
4.6 自定义行为
一些时候程序要求信号处理句柄运行在一个特定的堆栈上。为了实现这个目的，一个备用（alternate）堆栈区间必须用signaltstack函数指出来。这个函数使用的数据结构为signaltstack:
- int sigaltstack(const struct sigaltstack *ss, struct sigaltstack *oss);
它的结构成员解释如下。
该成员指向一个被用作堆栈的区域。系统中有个MINSIGSTKSZ常量，它定义了进行信号处理时所需的最小内存空间。系统中还有一个SIGSTKSZ常量，它定义了通常情况下处理时所需内存空间。该内存空间需要在调用signaltstack函数之间分配。
数据成员ss_size指出新堆栈的大小。如果这个值是错误的（inaccurate），当信号处理句柄执行时，它的行为就变得不可预知（你不能明确知道系统怎样处理这个信号）。
根据调用环境（calling circumstances），数据成员ss_flags可以具有少数几个不同的值。首先，当进程希望停用备用堆栈的时候，ss_flags会被设为SS_DISABLE。在这个情况下，ss_sp和ss_size被忽略，备用堆栈被禁止。注意，备用堆栈只能在当前句柄没有处理时禁止。
如果使用一个non-null值作为oss的实参去调用signaltstack，ss_flags将包含指示当前状态的信息。它们是：
- SS_DISABLE: 备用堆栈被停用。
- SS_ONSTACK: 备用堆栈当前正在被使用，并且现在不可以停用。
如果调用signaltstack 的oss实参不是null，会返回当前状态。调用成功返回0，否则返回-1。如果调用失败，errno也会相应的被设置。因为信号可以在任何一点被交付，所以很难被预测。出于这个原因，4.2BSD的缺省行为是：重新开始被中断的系统调用，重新提供还没有被转送的数据。在大多数时候这个行为是很不错的，并且也是所有BSD系统采用的缺省行为。可是，也有一些罕见的情况，你可能需要将这个特性关掉。你可以使用siginterrupt函数完成需求。使用很简单:
- int siginterrupt(int sig, int flag);
将sig参数设置为目标信号，并且设置flag为真(在这个情况下是1)。如果flag参数被设为假(在这个情况下是0)，那么缺省行为是重新启动系统调用。
4.7 等待信号
sigsuspend函数可以暂时将当前阻塞信号集改变为由sigmask指定的信号集。改变后，sigsuspend会等待，直到一个信号被交付。一旦一个信号被交付后，原先的信号集被恢复。由于sigsuspend调用在信号交付之后总是被终止，它的返回值总是-1，errno总是EINTR。下面是它的语法：
- int sigsuspend(const sigset_t *sigmask);
sigwait函数用set参数指定的信号集作为信号掩码。它会检查包含在这个特定集合内的是否有任何挂起信号，如果有的话，它将清除这个挂起的信号，并在sig参数中返回这个被清除信号的数值。如果没有信号挂起，sigwait将一直等待直到指定信号集合中的任何一个信号产生。下面是它的语法：
- int sigwait(const sigset_t *set, int *sig);
当信号被交付给进程（该进程安装了相应信号的处理句柄）时，进程将会切换到信号处理句柄中执行。例如，假设你的程序监听一个由配置文件设定的端口。你的进程安装了一个捕获SIGHUP信号的处理句柄来重新读取配置文件。一旦SIGHUP信号被交付给你的程序，进程将会执行信号处理句柄来重新读取配置文件。这里存在一个问题，你没有办法知道在进程执行过程中信号被交付的确切地点。你虽然可以使用一些下面列出的函数来将范围缩小，但是如果碰到像打开套接字，打开链接，或者其它那些首先需要清理后才能在新端口上监听 这些情况的时候呢？你怎样确定清理活动在那里开始，什么时候开始？如果你的程序正在等到输入，并且没有数据被传进来的时候，系统调用将被重启（system call will be restarted），所以从SIGHUP的返回将会继续等待。
这是使用setjmp和longjmp函数的一些情况，这些函数提供非本地分支(non-local branching)。为了使用这些setjmp函数，需要提供一个evn参数，如下：
- jmp_buff env;
- int sigsetjmp(sigjmp_buf env, int savemask);
- void siglongjmp(sigjmp_buf env, int val);
- int setjmp(jmp_buf env);
- void longjmp(jmp_buf env, int val);
- int _setjmp(jmp_buf env);
- void _longjmp(jmp_buf env, int val);
- void longjmperror(void);
首先，调用setjmp的返回为0，当前的环境将被保存在env中。接着，你可以在信号处理句柄内部调用对应的longjmp。一旦调用了longjmp，它将把执行环境恢复为env中保存的环境，并返回到最初setjmp被调用时的环境中。最初的setjmp调用返回那个传递给longjmp的va参数的值。
关于setjmp和longjmp函数一些说明：首先，这两个是不能混杂使用。也就是说，调用setjmp时保存的env变量不能传递给_longjmp调用。另外，调用setjmp的函数返回后，接下来调用longjmp将会发生错误。
The different calls have specific actions that they take. These actions are listed below:
不同的调用有特定的行为。这些行为在下面列出来：
- jmp和longjmp: 他们会保存（恢复）信号掩码，寄存器组和堆栈。
- _setjmp和_longjmp: 他们只保存(恢复)寄存器组和堆栈。
- sigsetjmp和siglongjmp: 只要savemask参数不是0，他们就保存(恢复)寄存器组，堆栈和信号掩码。
由于一些原因，如果env参数保存的东西被破坏，或者调用setjmp的函数返回了，longjmp函数将会调用longjmperror函数。如果longjmperror也返回了，程序将被异常终止。你可以使用与longjmperror有相同原形的函数来自定义longjmperror函数。缺省的longjmperror会在标准错误上输出”longjmp botch”，然后返回。
4.8 Alarms
- unsigned int alarm(unsigned int seconds);
alarm函数基本上是一个简单的闹钟时钟（alarm clock），同时也是一个很有用的函数。它允许进程在经过指定秒数之后收到一个通知。一旦闹钟时间到，进程将收到一个SIGALRM信号。任何随后的alarm调用都会覆盖原先的调用设定。alarm不像sleep函数，它不会被阻塞。
它有一些返回值需要值得你注意：首先，如果进程没有设定定时器，那么返回值是0。其次，如果有一个定时器被设定但还没有超时的话，那么会返回前一个调用到现在还有的剩余时间。
现在可以设定的最大时间是100,000,000秒 --- 已经是相当长的时间了。
- int getitimer(int which, struct itimerval *value);
getitimer函数会检索由第一个参数(which参数)描述的itimerval结构。第一个参数可选的选项将在下面说明：
- int setitimer(int which, const struct itimerval *value, struct itimerval *ovalue);
setitmer比先前的alarm调用提供了更稳定的接口。在BSD系统上，每个进程可以提供三种不同时间间隔的定时器。他们在下面讲述：
实时时钟实时的递减而不管进程在CPU上的实际花销时间(换句话说，它追踪自然时间natural time)。这允许进程设置一个基于自然实时时间（based on atural real time）的定时器。当实时定时器超时的时候，进程会收到SIGALRM信号。
虚拟定时器仅只递减进程在CPU上的执行时间，允许进程设定一个基于CPU使用率的定时器。当虚拟定时器超时的时候，进程收到SIGVTALRM信号
Profile定时器递减在CPU上的执行时间和代表进程执行的系统调用的时间。这对于那些要求静态剖析的解释程序是很有帮助的。当profile定时器超时的时候，进程收到SIGPROF信号。然而并不像实时和虚拟定时器那样，SIGPROF可以在系统调用的时候被发送；进程应该准备好重新执行被中断的系统调用。
本章将焦点放在了信号库上。这些信号及他们的使用方法对于系统编程是很重要的。信号允许系统管理员通知应用程序重新读取配置文件，从而使程序更稳定。其它重要的信号处理挂起在打开的文件描述符上的I/O操作。下一章讲述怎样利用这些I/O相关的信号。
(最近一段时间很忙，由于明天可以睡懒觉，所以今天下力气把它翻译完了。我负责的这部分中还有很多值得商榷的地方，欢迎大家多多批评指教。)
[ 本帖最后由 gvim 于 2006-2-25 02:38 编辑 ] |
|
免费注册
楼主: 雨丝风片
发表于 2006-02-20 13:01
发表于 2006-02-21 13:26
