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

Thomas DuBuisson <thomas.dubuisson@gmail.com> wrote:

> Brian Denheyer <briand@aracnet.com> wrote:
>
> > On Tue, 26 Jan 2010 10:54:03 -0800
> > Thomas DuBuisson <thomas.dubuisson@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 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.

> 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.