Implement THREAD_PRIORITY_TIME_CRITICAL

[Mike Hearn]

>>> Don't give up now as you will convince everyone else there is no solution
>>> and only your patch will make games work. Your attitude is defeatist
>>> because you're convinced that real time scheduling is your saviour. 

I don't want to do that! If there are other [robust] solutions I'm all 
ears. The patch did not take long to write, I am not attached to it. I 
am just having problems understanding what the alternatives are or where 
to start.

>>> I'm trying to help you here, so can you  do me one favour and try 2.6.17-rc1
>>> without any special patches and tell me how it currently performs?

Sure, it's decompressing now. Will be a while before I can report, I 
have an old computer so it will take some time to build.

>> Since it doesn't seem to work ...

Interesting theories. Now how do we test them? FWIW here is more detail 
on my original game:

* The game loads, the main menu audio starts. At this point audio is
   stable, maybe a click here and there. The static title screen fades
   out and a new one fades in.

* The new title screen then rotates around the screen (2D transform)
   spiralling away to reveal a 3D scene behind it with menu options and
   a spinning galaxy, ships etc. At this point, as the 3D scene is
   revealed, the audio breaks down completely and turns into white noise.

* Even with SCHED_FIFO about once every few hours the audio completely
   gives up and turns to white noise mess. So I guess Wines audio code
   should be more robust. Still, every few hours is playable, whereas
   straight away is not ...

So in this case either the CPU time goes way high when the 3D scene 
first appears, or maybe my 3D driver (nvidia) is not allowing 
pre-emption enough.

I guess I'm uneasy about this idea of keeping cpu time low, even for 
threads we control, because how do we debug it? How does one monitor a 
scheduler anyway? Maybe the problem is our audio thread is using too 
much cpu time - ok, how do we measure that? How much is too much? What 
threshold do we have to beat to get scheduling latency low enough to 
work properly? How do we figure out if the scheduler is doing what we 
think it's doing? What if it is a driver problem? This all seems very 
opaque to me.

thanks -mike