[Haskell-cafe] Are handles garbage-collected?
conal at conal.net
Thu Oct 28 20:16:57 EDT 2004
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.
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
> > triggers garbage collection when file descriptors run out. If not,
> > 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
> management, namely that it sometimes retains the resource (e.g.,
> or file descriptor) longer than necessary (resource leak) and
> not long enough (potentially disastrous programmer error). Whether
> resource is system RAM, file descriptors, video memory, fonts,
> bitmaps, graphics contexts, 3D polygon meshes, or whatever, I'd like
> to track the resource use and free unused resources correctly and
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>
More information about the Haskell-Cafe