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). Regards -- Adran Hey