So it's a bug in the garbage collector. It's closing a handle that clearly is still reachable, otherwise this would not have happened.
On Fri, Aug 13, 2010 at 10:53 AM, Simon Marlow <marlo...@gmail.com> wrote: > On 12/08/2010 21:59, Yitzchak Gale wrote: >> >> Wei Hu wrote: >>> >>> nonTermination _ = blackhole where blackhole = blackhole >> >> My original example was actually: >> >> process :: String -> String >> process = let x = x in x > > Ah yes, that works too. But other similar versions don't, like this one: > > process :: String -> String > process _ = let x = x in x > > Hence why I added the "tail" in my version. > > So what happens is this: > > - the recursive definition causes the main thread to block on itself > (known as a "black hole") > > - the program is deadlocked (no threads to run), so the runtime > invokes the GC to see if any threads are unreachable > > - the GC finds that > (a) the main thread is unreachable and blocked on a blackhole, so it > gets a NonTermination exception > (b) the Handle is unreachable, so its finalizer is started > > - the finalizer runs first, and closes the Handle > > - the main thread runs next, and the exception handler for writeFile > tries to close the Handle, which has already been finalized > > Really hClose shouldn't complain about a finalized handle, I'll see if I can > fix that. > > Cheers, > Simon > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
