[Haskell-cafe] Re: Lazy IO and closing of file handles

Benjamin Franksen benjamin.franksen at bessy.de
Wed Mar 21 16:25:55 EDT 2007

Benjamin Franksen wrote:
> Bertram Felgenhauer wrote:
>> Having to rely on GC to close the fds quickly enough is another problem;
>> can this be solved on the library side, maybe by performing GCs when
>> running out of FDs?
> Claus Reinke wrote:
>> in good old Hugs, for instance, we find in function newHandle in
> src/iomonad.c
>> [...snip...]
>>     /* Search for unused handle*/
>>     /* If at first we don't    */
>>     /* succeed, garbage collect*/
>>     /* and try again ...       */
>>     /* ... before we give up   */
>> so, instead of documenting limitations and workarounds, this issue should
> be
>> fixed in GHC as well.
> This may help in some cases but it cannot be relied upon. Finalizers are
> always run in a separate thread (must be, see
> http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html). Thus, even if
> you force a GC when handles are exhausted, as hugs seems to do, there is
> guarantee that by the time the GC is done the finalizers have freed any
> handles (assuming that the GC run really detects any handles to be
> garbage).

Sorry for replying to myself, but I just realized that the argument brought
forth by Boehm applies only to general purpose finalizing facilites, and
not necessarily to each and every special case. I think one could make up
an argument that file handles in Haskell are indeed a special kind of
object and that the language runtime /can/ run finalizers for file handles
in a more 'synchronous' way (i.e. GC could call them directly as soon as it
determines they are garbage). The main point here is that a file descriptor
does not contain references to other language objects.

The same would apply to all sorts of OS resource handles. However, the whole
argument is a priori valid only for raw system handles, such as file
descriptors. No idea what issues come up if one considers e.g. buffering,
or more generally, any additional data structure that gets associated with
the handle.


More information about the Haskell-Cafe mailing list