[Haskell-cafe] Re: help with threadDelay
Neil Davies
semanticphilosopher at googlemail.com
Wed Nov 29 05:57:52 EST 2006
On 29/11/06, Ian Lynagh <igloo at earth.li> wrote:
> On Wed, Nov 22, 2006 at 03:37:05PM +0000, Neil Davies wrote:
> > Ian/Simon(s) Thanks - looking forward to the fix.
>
> I've now pushed it to the HEAD.
Thanks - I'll pull it down and give it a try.
>
> > It will help with the real time enviroment that I've got.
>
> Lazy evaluation and GHC's garbage collector will probably cause
> headaches if you want true real time stuff.
So the wisdom goes, but I decided to try it and it works really
nicely. Yes, the GC can introduce additional "jitter", but I can
arrange for GC's to be performed at times more convinient and not on
the time critical path. I'm reliably able to get sub-millisecond
jitter in the wakeup times - which is fine for the application.
Laziness is fine - It'll help later when I can arrange evaluation
outside the time critical path.
Yea, I'd love a non-locking, incremental GC that returned within a
fixed (configurable) time - but until that time....
>
> > Follow on query: Is there a way of seeing the value of this interval
> > from within the Haskell program? Helps in the calibration loop.
>
> I don't follow - what interval do you want to know? You can't find out
> how long threadDelay took, but the lower bound (in a correct
> implementation) is what you ask for and the upper bound is what you get
> by measuring it, as you did in your original message.
I was trying to find out (in the running haskell) the value supplied
by (for example) -V RTS flag.
In order to get low jitter you have to deliberately wake up early and
spin - hey what are all these extra cores for! - knowing the
quantisation of the RTS is useful in calibration loop for how much to
wake up early.
>
>
> Thanks
> Ian
>
>
More information about the Haskell-Cafe
mailing list