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