What's the difference between slow system calls and fast system calls? I have learned that slow system call can block if the process catches some signals, because the caught signals may wake up the blocked system call, but I can't exactly understand this mechanism. Any examples would be appreciated.
There are in fact three gradations in system calls.
The distinction between “fast” and “slow” system calls is close to non-blocking vs. blocking, but this time from the point of view of the kernel implementer. A fast syscall is one that is known to be able to complete without blocking or waiting. When the kernel encounters a fast syscall, it knows it can execute the syscall immediately and keep the same process scheduled. (In some operating systems with non-preemptive multitasking, fast syscalls may be non-preemptive; this is not the case in normal unix systems.) On the other hand, a slow syscall potentially requires waiting for another task to complete, so the kernel must prepare to pause the calling process and run another task.
Some cases are a bit of a gray area. For example a disk read (
A slow system call is something like a TCP socket read() - if you don't have O_ASYNC (or whatever) set, it can wait for ever.
A fast system call is something like gettimeofday() or getpid(), both of which return information to the process that the kernel has immediately available.
Disk reads fall in the category of slow system calls. If a process does a read() on a true disk file, file descriptor, the kernel may have to read in one or more disk blocks to satisfy the read. Depending on the underlying file system's on-disk structure, this may mean reading the on-disk-inode to get the disk block number of an "indirect block", reading the indirect block to get the data block and then reading the data block itself. Quite time consuming, at least in terms of CPU cycles per disk access, probably worse today than it was in the Good Old Days.
I haven't seen this in ages, but the "bottom half" of old Unix disk drive device driver code would block signals/interrupts so that it was easier to maintain on-disk filesystem integrity. Occasionally, a buggy driver or failing disk would never deliver the disk block a process had asked for, and the process slept forever. Even a kill -9 did nothing to it.