10.5 Interrupted System Calls

One of the features of the early Unix system is that when a process is blocked in a "slow" system call, if a signal is captured, the system call is interrupted, and the system call returns an error, where errno is set to eintr. This can be achieved by using a number of events to wake up a blocked system call.
To support this feature, system calls are divided into two categories: slow system calls, and other system calls, so-called slow system calls, which refer to system calls that can be permanently blocked, including the following system calls:

• Read operations can block system calls forever, and if data is not ready for some file types (if present with certain types), file types include pipelines, terminals, and network devices.
• Write operations may also be blocked for some file types, if the data cannot be accepted immediately by these file types.
• Opening some specific file types may also block the calling process until certain conditions occur. For example, the opening of an end device needs to wait until a connected modem responds to the request. (until an attached modem answers the phone).
• The pause function and the wait function, which is defined by putting the calling process into sleep state until a signal is captured.
• Specific IOCTL operations
• Some interprocess communication functions (see Chapter 15th for details).

One notable exception to these slow system calls is any disk IO-related operation, although the read-write disk file will briefly block the calling process (the disk will queue the request and then execute the request) unless a hardware error occurs, and the IO operation will always return quickly without blocking the calling process.

One condition that was handled by interrupted system calls, for example, was when aprocess initiates a read from a terminal Device and the user at the terminal walks away from the terminal for a extended period. In this example, the process could is blocked for hours or days and would remain so unless the system is taken down.

Posix.1 's definition of interrupted reads and writes was modified in the 2001 version of the standard, and earlier implementations gave two different options for reads or writes that had processed some of the data. If read has been accepted and transferred to a portion of the data in the application's buffer, but has not yet reached the number of application requests, the result could be a system call execution failure, set errno to Eintr, or allow the system call to succeed, and return some of the data already described. Similarly, if the writes function is interrupted after transferring some of the data, the operating system either sets the system call to fail and sets the errno to Eintr, or allows the system call to succeed and returns the number of parts that have been written successfully. Historically, systems that inherit from System V set the system call to fail in the above scenario, and the implementation that inherits from BSD returns a partial success. In the 2001 version of the POSIX.1 standard, the definition of BSD type was selected.

Now we need to deal with the interrupted system call: The return of the error must be handled in a display. The typical processing code is shown below (assuming a read operation and assuming we want to restart the read operation after the operation is interrupted):

2. again:
4. if((n = read(fd, buf, BUFFERSIZE)<0)
6. {
8. if(errno == EINTR)
10. {
12. goto again;/*just an interrupted system call*/
14. }
16. /*handle other errors*/
18. }

To avoid application processing of interrupted system calls, 4.2BSD introduces the automatic restart of some of the interrupted system calls, which can be automatically restarted after being interrupted including:ioctl,read,readv,write,writev,wait, and Waitpid, as we mentioned, the previous five system calls may be interrupted when the slow device is operating, the system calls wait and the waitpid is always interrupted when the signal appears, Because this is problematic for applications that do not want to be restarted when the operation is interrupted, 4.3BSD allows the process to not enable this feature of a certain signal.

POSIX.1 requires that the system call be restarted only when the interrupt signal is affected by the Sa_restart function, as we will see in section 10.14, which is used for the parameters of the sigaction, allowing the application to request a reboot of the interrupted system call.

Historically, when using function signal to establish a signal processing function, the System V never restarts the system call by default, and the BSD will restart when the system call is interrupted by a signal interrupt, and the implementation is related to the interrupt. On freebsd8.0,linux3.2.0 and Mac OS X10.6.8, when the signal processing function is used signal installation, the interrupted system call is restarted, and the default behavior on Solaris 10 is to return an error (EINTR). By using the signal function we implemented in Figure 10.18, we can avoid dealing with these implementation differences.

4.2BSD introduces an automatic restart of interrupted system calls one of the reasons is that the program designer does not know whether the input or output device is a slow device, if we write an application may be used interactively, then it may be a slow device to read and write operations, because the terminal equipment belongs to this type, When a signal is captured in such a program and the system does not provide an automatic restart, we must check each read and write function for any interrupted errors, and then process the read and write again.

Figure 10.3 summarizes the signal functions and the definitions provided by different implementations:

never

Functions	System	Signal handler remains installed	Abili TY to block signals	Automatic Restart of interrupted system calls?
signal	ISO c,posix.1	unspecified	unspecified	unspecified
signal	v7,svr2,svr3			never
signal	svr4,solaris
signal	4.2BSD	*	*	always
signal	4.3bsd,4.4bsd,freebsd,linux,mac OS X	*	*	default
sigaction	posix.1,4.4bsd,svr4,freebsd,linux,mac OS x,solaris	*	*	Optional

Figure 10.3 features provided by different signal implementations

It is important to note that UNIX systems from different developers have different conditions in the table above, for example, the Sigaction function under SunOS 4.1.2 restarts an interrupted system call by default.
In Figure 10.18, we provide our own signal function, which will attempt to restart the interrupted system call (in addition to the SIGALRM signal), in Figure 10.19 we provide another function signal_intr, which never attempts to perform a restart operation.

A more detailed discussion of the interrupted system calls will be made in 14.4. (About function Select and poll)

From for notes (Wiz)

10.5 Interrupted System Calls