ptg10805159Appendix C Chapter 11Solutions 925
10.10 On one system used by the author,the value for the number of seconds increased
by 1 about every 60–90 minutes. This skew occurs because each call tosleep
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 callsleepagain.
Aprogram such as thecrondaemon 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 thetm_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 3.2.0, Mac OS X 10.6.8, and Solaris 10, the signal handler for
SIGXFSZis never called. Butwritereturns 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 8.0, the signal
handler is called on the next attempt to write 100 bytes, and thewritecall
returns−1witherrnoset toEFBIG(‘‘File too big’’).
On all four platforms, if we attempt an additionalwriteat the current file offset
(the end of the file), we will receiveSIGXFSZandwritewill fail, returning− 1
witherrnoset toEFBIG.10.12 The results depend on the implementation of the standardI/O library: how the
fwritefunction handles an interruptedwrite.
On Linux 3.2.0, for example, when we use thefwritefunction to write a large
buffer,thefwritefunction callswritedirectly for the same number of bytes.
While in the middle of thewritesystem call, the alarm fires, but we don’t see
the signal until the write completes. It appears as if the kernel is blocking the
signal while we are in the middle of thewritesystem call.
In contrast, on Solaris 10, thefwritefunction callswritein 8 KB increments
until the entireamount is written. When the alarm fires, it is caught, interrupting
the call tofwrite.After we return from the signal handler, we return to the
loop inside thefwritefunction and continue writing in 8 KB increments.Chapter 11
11.1 Aversion of the program that allocates the memory dynamically instead of using
an automatic variable is shown in FigureC.12.