What's the rationale behind it? What would the bad consequences be if a process doing I/O is allowed to handle signal?
An Uninterruptible sleep state is one that won't handle a signal right away. It will wake only as a result of a waited-upon resource becoming available or after a time-out occurs during that wait (if the time-out is specified when the process is put to sleep).
One of the curious features of Unix systems (including Linux) is the "uninterruptible sleep" state. This is a state that a process can enter when doing certain system calls. In this state, the process is blocked performing a sytem call, and the process cannot be interrupted (or killed) until the system call completes.
An uninterruptible process is a process which happens to be in a system call (kernel function) that cannot be interrupted by a signal. To understand what that means, you need to understand the concept of an interruptible system call. The classic example is read() .
Generally, a process is put into D state when waiting for some sort of I/O to complete. The process has made a call into the kernel and is waiting for the result. During this period, it is unable to be interrupted.
According to the Linux Developers Documentation, it is to prevent data loss and avoid hardware getting into an inconsistent state.
Imagine what could occur if a read()
(such as from disk) were interruptible and the signal handler, among other duties, altered the read buffer. Since the signal is asynchronous, the read results would not be reproducible. Similar chaos would ensue if writing were interrupted.
Now that I've read the book "The Design of the Unix Operating Systems" by Maurice Bach, let me answer this question by myself.
In short, making I/O uninterruptible is for the purpose of making the I/O task finish ASAP, without being interfered by signals.
Some related knowledge that I gained from the book:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With