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:[EMAIL PROTECTED]
Sent: Sunday, October 24, 2004 12:50 PM
To: Conal Elliott
Cc: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>
_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
