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 <[EMAIL PROTECTED]> _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
