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".
More comments? - Conal -----Original Message----- From: Remi Turk [mailto:[EMAIL PROTECTED] Sent: Sunday, October 24, 2004 1:08 PM To: Conal Elliott Cc: [EMAIL PROTECTED] 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 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. > > Cheers, > > - 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... Greetings, Remi -- Nobody can be exactly like me. Even I have trouble doing it. _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe