On Tue, 26 Jan 2010 10:54:03 -0800
> > 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.
How about this:
f = putStrLn "foo"
doEvent f usDelay = do forkIO f
threadDelay usDelay
doEvent f 1000000
main = doEvent f 1000000
which seems to work. That makes me suspicious :-|
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'.
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.
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.
Cheers,
Thomas