Re: Xterm Hangs - Possible scheduler defect?

["Chad N. Tindel" <chad@tindel.net>]

> >I'm all for allowing people to shoot themselves in the foot.  That doesn't
> >mean that it is OK for a single userspace thread to mess up a 64-way box.
> 
> If root has explicitly stated that the thread in question is the highest 
> priority thing on the entire machine, why would it not be okay.  The 
> fact that root made a mistake is the issue here, not that the system 
> didn't protect itself.

Yeah, I realized when I left for lunch that this statement wasn't as clear
as I would like it to be.

I think what we have are the need for two levels of applications:

1.  That which wishes to be the highest priority userspace application, and
wishes to preempt all other userspace applications.  Such an application is
OK being preempted by the kernel when the kernel needs to do work.  IMHO, this
should be the default behavior for any SCHED_FIFO application.  If one of these
has a bug and goes CPU-bound, the worst it can do is prevent other apps from
ever using the CPU it is on.

2.  Applications which actually want to be the highest priority thing on
the system, including being higher than the kernel.  These applications are
OK with the fact that they may cause system hangs and deadlocks, and are
careful not to shoot themselves in the foot.

> There are professionals who use linux for audio as well, it's not just 
> home systems.  That said, you unify them with reasonable defaults, and 
> the ability for root to override them.

OK.  Would you say it would be a reasonable default to have SCHED_FIFO userspace
threads running at a lower priority than essential kernel threads (say, the
load balancer and the events thread), and give root the ability to explicitly 
have userspace threads preempt the kernel?

Chad