RE: [Haskell-cafe] Are handles garbage-collected?

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, 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:rturk@science.uva.nl] Sent: Sunday, October 24, 2004 1:08 PM To: Conal Elliott Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Are handles garbage-collected? On Sun, Oct 24, 2004 at 12:19:59PM -0700, 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.

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.