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