On Wednesday 30 March 2005 10:18, Muli Ben-Yehuda wrote: > Why do you think so? D means that a process is holding a lock. Do you > mean "bugs" in the sense of "long lock holding times"?
Even worse, I have seen too many occasions when "long" actually was "unbounded". When kernel code does uninterruptible sleep it actually breaks a system call API promisses (e.g: that SIGKILL will always kill a process). This can be tolerated if the code can assure this condition will only be present for a transient and short time (for some definition of "short"). The problem, IMO is that in kernel coding the "easy" down(&sem) is the uninterruptible version and programmers has to type the long down_interruptible(&sem) to get the "nice" version. If you add to this the obvious complication of checking and handling the case where your sleep is actually interrupted you'll find many situations where kernel coders might have used interruptible sleep but took the easy way. -- Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron ICQ UIN: 16527398 Microsoft want you to "Get the Facts". I suggest you better read the US court "FINDINGS OF FACT" first: http://usvms.gpo.gov/ms-findings2.html ================================================================= 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]
