>> They should be waiting in TASK_UNINTERRUPTIBLE, and we should add a
>> flag to distinguish between "increases load average" and "doesn't".
>
> The disadvantage of this approach is that it encourages people to be lazy
> and sleep with signals disabled, instead of implementing proper cleanup
> code.
>
> I'm more in favour of removing TASK_UNINTERRUPTIBLE entirely, or at least
> making people apply for a special licence to be permitted to use it :)
>
> --
> dwmw2
Consider this. An application writes to /dev/dsp0, and ymfpci
(for example) start DMA. Then user interrupts the app with ^C.
When ymfpci gets ->release() call, it has to tell the chip
to stop DMA, then wait until it's complete. If it tries to
wait with TASK_INTERRUPTIBLE, schedule() will return immediately,
and in essense do a busy loop with CPU pegged at 100%.
Same thing happens in USB, only there it's worse: a spinning
application locks out khubd and whole subsistem dies.
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:17 EST