Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!mailrus!tut.cis.ohio-state.edu!rutgers!ucsd!ucsbcsl!eiffel!bertrand
From: bertrand@eiffel.UUCP (Bertrand Meyer)
Newsgroups: comp.lang.eiffel
Subject: Re: garbage collection
Message-ID: <129@eiffel.UUCP>
Date: 23 Mar 89 02:53:25 GMT
References: <2152@vlot.cs.vu.nl>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 57

Subject: Re: garbage collection
Newsgroups: comp.lang.eiffel
References: <2152@vlot.cs.vu.nl>

From <2152@vlot.cs.vu.nl>, jos@cs.vu.nl (Jos Warmer):

> 
> 1. In the library class FILE one can create a FILE object,
> open it and use it.
> If the FILE object is not referenced anymore, the memory used by it
> will be reclaimed by the garbage collector.
> However, each file that is opened should be closed before the FILE object
> is destroyed.
> 
> This can not be forced by the FILE class, but it is left to the client.
> It should be much safer if the FILE class could ensure that each file
> is closed before the object pointing to it is destroyed.

> In Unix, and probably elsewhere too, only a limited number of open
> file descriptors are allowed.  So once you open a number of files and
> forget to close them, you cannot open files anymore after some time.
> See class OPEN at the end of this article.


    In version 2.2 the library class MEMORY will include an argumentless
procedure called dispose, to be invoked by the garbage collector (if
active) when an object is freed. The original version of this class
has an empty body and hence does nothing. Any class can inherit
from MEMORY and redefine this procedure to do something, for instance
close a file as in Mr. Warmer's example.

Two caveats:

    - The exact details are still subject to change.

    - The next version (Eiffel 3, end of 1989) will support the
    possibility of treating all objects as persistent (the set of all
    objects of an Eiffel session becoming a database). In this context
    the problem addressed by Mr. Warmer becomes part of a larger
    requirement (describing what should be done to any object when
    the session terminates, or when it is stored to a file by an automatic
    mechanism). This means that the 2.2 solution may be overridden at that
    time by a more general scheme.

    
>    [2. - Problem of freeing space for data structures allocated not
>    from Eiffel but from external C functions, through malloc.]
>    Of course you can provide the programmer with a function to free the
>    memory allocated by [an external C] function, but this solution excludes
>    garbage collection.

    Clearly we cannot provide a garbage collector for C. Nor do we want to
go into the horrors of programmer-supplied deallocation as in C extensions.
In 2.2, with the mechanism described above, you can ensure that the
dispose procedure calls any C routines that are needed to free C storage.

-- Bertrand Meyer
bertrand@eiffel.com