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
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@gclements.plus.com] Sent: Sunday, October 24, 2004 12:50 PM To: Conal Elliott Cc: haskell-cafe@haskell.org Subject: RE: [Haskell-cafe] Are handles garbage-collected? Conal Elliott wrote: 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