[Haskell-cafe] scheduling an alarm
thomas.dubuisson at gmail.com
Wed Jan 27 01:41:44 EST 2010
Brian Denheyer <briand at aracnet.com> wrote:
> On Tue, 26 Jan 2010 10:54:03 -0800
> Thomas DuBuisson <thomas.dubuisson at gmail.com> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe