[Haskell-cafe] Are handles garbage-collected?
conal at conal.net
Sun Oct 24 18:47:29 EDT 2004
Thanks, Remi (and other responders). I did indeed mean that GC of
non-RAM resources would be triggered by _those_ resources getting low
rather than RAM. That is, there would be many per-type collectors, each
with its own trigger. And maybe really only a small number different
collection algorithms, but clearly separated spaces and triggers. This
idea sounds fairly simple to me, so maybe not "only theoretical".
From: Remi Turk [mailto:rturk at science.uva.nl]
Sent: Sunday, October 24, 2004 1:08 PM
To: Conal Elliott
Cc: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Are handles garbage-collected?
On Sun, Oct 24, 2004 at 12:19:59PM -0700, Conal Elliott wrote:
> 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
> - Conal
IMO, it does indeed have those same drawbacks. (Although the
traditional "explicit memory management model" is alloc/free,
which is much worse than bracket/withFile)
However, Garbage Collection is usually based only on memory.
Using GC for file-handle-closing therefore means that one will
close garbage file-handles when memory is getting low, instead of
when file-handles are almost used up...
The theoretical solution (and probably _only_ theoretical) is
implementing a lot of garbage collectors: one for memory, one for
open files, one for sockets, one for 3D polygon meshes etc etc...
Nobody can be exactly like me. Even I have trouble doing it.
More information about the Haskell-Cafe