Re: [Haskell-cafe] scheduling an alarm

On Tue, 26 Jan 2010 22:41:44 -0800 Thomas DuBuisson wrote:

Brian Denheyer wrote:

...

On Tue, 26 Jan 2010 10:54:03 -0800 Thomas DuBuisson wrote:

...

...

doEvent f usDelay = forkIO $ threadDelay usDelay doEvent f usDelay f

Are you sure that's right ? It seems to be a memory-gobbling infinite loop...

Infinite loop? yes, that is what you wanted. Memory gobbling? Why would you think that? Are you assuming no TCO and a full stack push on every function call? Haskell compilers don't work that way.

Why would I think that ? I think that because the following code: import Control.Concurrent f = putStrLn "foo" doEvent f usDelay = do forkIO $ threadDelay usDelay doEvent f usDelay f _really_ _does_ start to consume all of the memory on my system, that's why. I don't know why, but that's what it does on my system. It's not obvious to me that it should do that. So maybe ghci is not doing TCO.

1) There are a million ways to do this - why does one working make you suspicious of another? You can always test the other - it does work so long as you fix the missing 'do'.

The "suspicious" part, that was a joke. Having something that works is nice, making sure I understand it is better. I haven't used the Concurrent stuff before, so I'm just being tentative.

2) It strikes me as funny you suspect the first way when there is zero fundamental difference between that and the way you posted except that: a) My version maintains the correct delay. b) My version forks the doEvent call and runs the action in the older thread while yours forks the action thread and keeps the doEvent in the older thread. I suppose keeping the doEvent as the old thread is good so you can kill it with the original ThreadID that would be returned to the caller.

Thanks for the explanation, as I said I'm a little fuzzy on what constitutes a thread, so the two versions will help. One interesting thing I noticed in the docs (which is not important for what I am trying to do, just interesting): There is no guarantee that the thread will be rescheduled promptly when the delay has expired, but the thread will never continue to run earlier than specified. I expect that this means "promptly" in the sense of not accurately, however I wonder what the upper bound on the (potential) delay is ?

Some people miss the fact that threadDelay is a us value and an Int type - this limits the maximum delay to something like 35 minutes (assume a 32 bit Int) or even just 134 seconds if you go by Haskell 98 minimum of 27 bit Ints. Just making sure you realize this seeing as we are talking about delays in that order of magnitude. I advise the overly-complex but functional Control-Event package if you want longer delays.

I did notice that the delay is in us. 35 minutes is plenty of time. I can always delay twice ;-) Thanks for pointing me to control event, that looks useful ! Brian