Chapter 10
10.1 | |
10.3 | Figure C.10 shows the stack frames.Figure C.10. Stack frames before and after longjmp |
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. |
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. |