threadDelay problem

Adrian Hey ahey at
Sat Jan 10 15:29:41 EST 2004

On Wednesday 07 Jan 2004 8:01 pm, John Meacham wrote:
> On Wed, Jan 07, 2004 at 12:38:11PM -0000, Simon Marlow wrote:
> > > The idea is to stop a Haskell prog with no runable threads or events
> > > to process hogging CPU time. I was a bit dissapointed to find
> > > that despite
> > > this on my (otherwise idle) machine the above code was still
> > > using 96% of cpu time.
> > >
> > > But fiddling about a bit I found that by changing the thread
> > > delay in the
> > > main loop to 20 mS the CPU usage dropped to 1% or so, which
> > > is much more
> > > acceptable (well it did say 1/50 th second accuracy in the docs :-).
> >
> > Yes, threadDelay will round the interval down to the nearest multiple of
> > the resolution, so you were effectively using threadDelay 0.  This ought
> > to be mentioned in the documentation.
> this seems like the incorrect (and inconsistant with system interfaces)
> approach. rounding up is the norm. alarm and sleep both say you will
> sleep at least as long as the time specified. and threadDelay should
> behave similarly. it is the more useful semantics anyway, since you are
> usually waiting for an event to occur, and it is pretty much always okay
> to wait to long, but can be bad (as in this case) to wait to short.
>         John

I'll vote for that too. It seems unlikely that this change would break
any existing code and, as John has says, waiting for longer than specified
seems like the lesser of two possible evils (especially when there's
no absolute guarantee that the thread will resume as soon as the
specified delay time has elapsed in any case).

Adran Hey

More information about the Glasgow-haskell-users mailing list