Mon, 11 Sep 2000 03:49:05 -0700, Simon Marlow <[EMAIL PROTECTED]> pisze:
> > The Haskell's runtime could do something with it: detect the "too many
> > open files" error and try to suck some lazily read files.
>
> I suppose it could try doing a full GC to detect the dead handles, then
> somehow arrange that the finalizers all run before anything else. This
> sounds fairly complicated though.
GC should be done before (to avoid sucking dead files), but it's not
enough. In this case handles are not dead because their lazily read
contents are not dead.
The idea is similar to trying to evaluate random thunks when going
out of memory. Bit this applies to a different resource, is safe and
will definitely free resources.
> I'm of the opinion that readFile/hGetContents are useful for small
> programs, but for larger tasks you need to manage your I/O more
> explicitly.
I disagree and think that it's possible and worth to make
readFile/hGetContents more reliable for larger programs too.
As I have said before, hClose on a semi-closed handle should perform
GC and suck the file before closing if the contents are still alive.
This should be easier than automatic "too many open files" recovery;
it applies locally to a single handle. Using such hClose in Jan's case
(and thus reading files immediately) would help in the absence of
"too many open files" recovery.
readFile should behave such that the semantics is as close as possible
to immediate sucking the whole file, but still being lazy most of
the time. Outside I/O laziness never hurts except of performance.
This principle should apply to readFile too.
There is no nice "strict readFile" now. Improved hClose gives not only
that, but allows reading most of the file lazily and deciding at some
point that the file must be closed without the danger of losing end
of its contents.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZAST�PCZA
QRCZAK
