[Haskell-cafe] Thread priority?

[Don Stewart]

semanticphilosopher:
> Count me in too
>
> I've got a library that endeavours to deliver 'rate-equivalence' - i.e  
> there may be some jitter in when the events should have occurred but  
> their long term rate of progress is stable.
>
> Testing has shown that I can get events to occur at the right time  
> within 1ms (99%+ of the time, with 50%+ of the events < 0.5ms) - choose 
> your O/S carefully though. And this is without resorting to marking the 
> threads as real time with the kernel. If it matters you can tune the 
> scheduling to further reduce the timer scheduling latency (at the cost of 
> more CPU) and increase the fidelity of event timing another order of 
> magnitude or more.
>
> As for 'garbage collection ruins my real time properties' argument -  
> I've been pragmatic about this, you can configure the scheduler to go  
> and perform a GC if it knows that it is going to sleep for a while (yes, 
> this doesn't resolve the issues of external events arriving in that time 
> but read on) but not perform that too often. Turning off GHCs timers (to 
> stop it garbage collecting after it has actually been idle for a while) 
> and having code that doesn't create vast amounts of garbage means that a 
> GC takes <0.1ms.
>
> Now if I could see within Haskell the amount of heap that has been  
> recently mutated and some other GC statistics when it was running I  
> could even decide to schedule that more effectively.

You could actually do this by importing symbols from Stats.c in the
runtime (the same variables used for +RTS -sstderr output). I'm not sure
anyone's  ctually tried this yet though, but the effect would be a
program that can monitor its own heap health.

-- Don