[Haskell-cafe] Are handles garbage-collected?

Remi Turk rturk at science.uva.nl
Mon Oct 25 14:55:46 EDT 2004


On Mon, Oct 25, 2004 at 02:14:28PM +0100, Simon Marlow wrote:
> On 24 October 2004 20:51, Sven Panne wrote:
> 
> > IMHO it would be best to use explicit bracketing where possible, and
> > hope for the RTS/GC to try its best when one runs out of a given
> > resource. Admittedly the current Haskell implementations could be
> > improved a little bit in the last respect.
> 
> Indeed, GHC could/should try to free up file descriptors when they run
> out.  It's a bit tricky though.
Hm, I'm not sure about the "should". Garbage collection is meant
for memory, and anything making that less clear makes people
more likely to depend on incorrect assumptions.
And redefining GC to be a collection of _all_ garbage, instead of
just memory doesn't sound so fantastic either.

> At the moment performGC doesn't actually run any finalizers.  It
> schedules a thread to run the finalizers, and you hope the thread runs
> soon.  So if you're running performGC for the purposes of finalization,
> then almost certainly (performGC >> yield) is better.  I've been
> wondering whether having a more synchronous kind of finalizer would be a
> good thing.
Synchronous finalizers seem to be difficult to implement in e.g.
the JVM, so may make a JVM-backend more difficult. (I'm thinking
about how CPython vs Jython go about closing file-handles...
CPython uses (primarily) reference-counting, so files get closed
as soon as they aren't referenced anymore, which lots of people
now depend on. Jython uses Java-GC, so some CPython programs
may suddenly fail...)

> Nevertheless, I agree with the general sentiment on this thread that
> file descriptors shouldn't be treated as a resource in the same way as
> memory.
>
> Cheers,
> 	Simon

Groeten,
Remi

P.S. Why do so many people (including me) seem to come to Haskell
     from Python? It can't be just the indentation, can it? ;)

-- 
Nobody can be exactly like me. Even I have trouble doing it.


More information about the Haskell-Cafe mailing list