| 10.1 | The program terminates the first time we send it a signal. The reason is that the pause function returns whenever a signal is caught. |
| 10.3 | Figure C.10 shows the stack frames.
The longjmp from sig_alrm back to main effectively aborts the call to sig_int. |
| 10.4 | We again have a race condition, this time between the first call to alarm and the call to setjmp. If the process is blocked by the kernel between these two function calls, the alarm goes off, the signal handler is called, and longjmp is called. But since setjmp was never called, the buffer env_alrm is not set. The operation of longjmp is undefined if its jump buffer has not been initialized by setjmp. |
| 10.5 | See "Implementing Software Timers" by Don Libes (C Users Journal, vol. 8, no. 11, Nov. 1990) for an example. |
| 10.7 | If we simply called _exit, the termination status of the process would not show that it was terminated by the SIGABRT signal. |
| 10.8 | If the signal was sent by a process owned by some other user, the process has to be set-user-ID to either root or to the owner of the receiving process, or the kill won't work. Therefore, the real user ID provides more information to the receiver of the signal. |
| 10.10 | On one system used by the author, the value for the number of seconds increased by 1 about every 6090 minutes. This skew occurs because each call to sleep schedules an event for a time in the future, but is not awakened exactly when that event occurs (because of CPU scheduling). In addition, a finite amount of time is required for our process to start running and call sleep again.
A program such as the cron daemon has to fetch the current time every minute, as well as to set its first sleep period so that it wakes up at the beginning of the next minute. (Convert the current time to the local time and look at the tm_sec value.) Every minute, it sets the next sleep period so that it'll wake up at the next minute. Most of the calls will probably be sleep(60), with an occasional sleep(59) to resynchronize with the next minute. But if at some point the process takes a long time executing commands or if the system gets heavily loaded and scheduling delays hold up the process, the sleep value can be much less than 60. |
| 10.11 | Under Linux 2.4.22 and Solaris 9, the signal handler for SIGXFSZ is never called. But write returns a count of 24 as soon as the file's size reaches 1,024 bytes.
When the file's size has reached 1,000 bytes under FreeBSD 5.2.1 and Mac OS X 10.3, the signal handler is called on the next attempt to write 100 bytes, and the write call returns 1 with errno set to EFBIG ("File too big"). |
| 10.12 | The results depend on the implementation of the standard I/O library: how the fwrite function handles an interrupted write. |
