|Subject:||Re: [Haskell-cafe] scheduling an alarm|
|Date:||Tue, 26 Jan 2010 22:41:44 -0800|
Brian Denheyer <[email protected]> wrote:
On Tue, 26 Jan 2010 10:54:03 -0800
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:
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.
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [Haskell-cafe] scheduling an alarm, Brian Denheyer|
|Next by Date:||[Haskell-cafe] Re: classes with types which are wrapped in, Andrew U. Frank|
|Previous by Thread:||Re: [Haskell-cafe] scheduling an alarm, Brian Denheyer|
|Next by Thread:||Re: [Haskell-cafe] scheduling an alarm, Brian Denheyer|
|Indexes:||[Date] [Thread] [Top] [All Lists]|