[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