[Haskell-cafe] Are handles garbage-collected?

[Conal Elliott]

Thanks for the explanation and example.  I think the goal is to close
the pipe (for instance) asap after writing is finished.  GC imposes a
delay, but so does bracketing, especially where modularity is desired.
Consider that the bracketing IO code calls separately defined IO code,
which makes the final write to a pipe but then do more work before
returning.  In that case, a GC-like solution may close the pipe, release
the lock or whatever, sooner than the bracket solution, especially if
the descriptor GC were particularly eager.   Just as with memory
management, stack-based allocation and freeing thwarts modularity or
efficiency or both, and automatic GC is a possible solution, if it
performs well enough.

Cheers,
 
     - Conal

-----Original Message-----
From: Glynn Clements [mailto:glynn at gclements.plus.com] 
Sent: Sunday, October 24, 2004 12:50 PM
To: Conal Elliott
Cc: haskell-cafe at haskell.org
Subject: RE: [Haskell-cafe] Are handles garbage-collected?


Conal Elliott 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?
> 
> 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.

File descriptors aren't simply a "resource" in the sense that memory
is. Closing a descriptor may have significance beyond the process
which closes it. If it refers to the write end of a pipe or socket,
closing it may cause the reader to receive EOF; if it refers to a
file, any locks will be released; and so on.

-- 
Glynn Clements <glynn.clements at virgin.net>