[Haskell-cafe] Are handles garbage-collected?

[Conal Elliott]

I'm puzzled why explicit bracketing is seen as an acceptable solution.
It seems to me that bracketing has the same drawbacks as explicit memory
management, namely that it sometimes retains the resource (e.g., memory
or file descriptor) longer than necessary (resource leak) and sometimes
not long enough (potentially disastrous programmer error).  Whether the
resource is system RAM, file descriptors, video memory, fonts, brushes,
bitmaps, graphics contexts, 3D polygon meshes, or whatever, I'd like GC
to track the resource use and free unused resources correctly and
efficiently.

Cheers,

     - Conal

-----Original Message-----
From: haskell-cafe-bounces at haskell.org
[mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Tomasz Zielonka
Sent: Sunday, October 24, 2004 1:33 AM
To: Peter Simons
Cc: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Are handles garbage-collected?

On Sun, Oct 24, 2004 at 01:39:06AM +0200, Peter Simons wrote:
> What happens when a System.IO.Handle falls out of scope
> without being explicitly hClosed? Is that a resource leak?
> Or will the RTS close the handle for me?

AFAIK, Handles have finalisers which close them, but I don't know if GHC
triggers garbage collection when file descriptors run out.  If not, you
will have problems if you manage to run out of fds between GCs.

How about using bracket to introduce explicit close on end of scope?

Best regards,
Tom

-- 
.signature: Too many levels of symbolic links
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe