On Mon, Jul 22, 2002, Omer Zak wrote about "Why do we need uninterruptible sleep? (was: Re: killing "uninterruptible sleep" process)": > Why then there is such a thing as "uninterruptible sleep" in Unix/Linux? > What useful purpose (besides full Posix conformance) does this serve?
As far as I know, processes are put into uninterruptible sleep (D) state when it is either too complicated, or the programmer was too lazy, to decide what to do in the case that the process would be killed during the sleep. The quintessential case is a process that is waiting for a disk page to be copied to its memory, or for one of its virtual-memory pages to be swapped into core from disk. What would (or should) happen if a process will be killed at this point? When the disk hardware is finally ready to fetch the page, the process is no longer there and its memory pages have gone the way of the dodo. It would be "simpler" if the process simply could not be killed at this point. However, A good kernel design should only use the D state sparingly, and only for very short term operations that are sure to succeed (such as fetching a page from disk). A bad design, on the other hand, would use it in many places where a process being killed might complicate the programmer's life, such as when waiting for RPC replies (such as in NFS) or the SMB stuff you may have noticed. In my opinion, all these cases which might result in processes being stuck in the D state for a long time, should be considered bugs in the kernel and should be fixed. -- Nadav Har'El | Monday, Jul 22 2002, 13 Av 5762 [EMAIL PROTECTED] |----------------------------------------- Phone: +972-53-245868, ICQ 13349191 |Entropy: Not just a fad, it's the future! http://nadav.harel.org.il | ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]