Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lll-winken!uunet!mcvax!hp4nl!botter!star.cs.vu.nl!jos@cs.vu.nl
From: jos@cs.vu.nl (Jos Warmer)
Newsgroups: comp.lang.eiffel
Subject: garbage collection
Message-ID: <2152@vlot.cs.vu.nl>
Date: 14 Mar 89 10:14:39 GMT
Sender: jos@cs.vu.nl
Reply-To: jos@cs.vu.nl (Jos Warmer)
Organization: VU Informatica, Amsterdam
Lines: 91

Some problems with garbage collection:

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.

2. In a class that acts as an interface to external (C) functions sometimes
   memory is allocated by C functions.  For example the class STRING from
   the basic library.

   If a STRING object is not referenced anymore, the memory used by it
   will be reclaimed by the garbage collector.
   However, the garbage collector cannot know whether memory was allocated
   by external functions.  So the memory allocated by the external function
   will never be reclaimed.

   Of course you can provide the programmer with a function to free the
   memory allocated by the external function, but this solution excludes
   garbage collection.

A possible solution:

In C++ so-called destructors can be defined.  A destructor is a routine
that is called on an object when the object is being freed.
A destructor contains code that performs some cleanup before the object
is destroyed.

These destructors can be used to solve the problems described above.
I cannot find a way to solve these problems in eiffel.  Should such
a feature be added eiffel, or are there other solutions.

===========================================================================
			     Jos Warmer
			     jos@cs.vu.nl
			     ...uunet!mcvax!cs.vu.nl!jos
===========================================================================
	class OPEN
	        -- example of forgetting to close files.
	inherit
		MEMORY; STD_FILES

	feature
	    Create is
	    do
		open_files;
		open_files;
	    end;

	    open_files is
	    local
		f : FILE;
		i : INTEGER;
	    do
		from  f.Create("a");
		      f.open_write;
		until f.error /= 0
		loop
		    f.Create("a");
		    f.open_write;
		    i := i + 1;
		    putint(i); putstring(" ");
		end;

		new_line;
		putstring("error nr   "); putint(f.error); new_line;
		putstring("open files "); putint(i      ); new_line;
		full_collect
	    end;
	end

================ the output of open ===============================
class FILE, error on open_write, with file-name ``a'': Unable to open
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 
error nr   2
open files 23
class FILE, error on open_write, with file-name ``a'': Unable to open
 
 error nr   2
 open files 0
===================================================================