Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!rochester!udel!haven.umd.edu!purdue!mentor.cc.purdue.edu!noose.ecn.purdue.edu!samsung!mips!spool.mu.edu!decwrl!argosy!news
From: news@argosy.UUCP (USENET News System)
Newsgroups: comp.lang.scheme
Subject: Re: Ports & GC
Message-ID: <1262@argosy.UUCP>
Date: 26 Apr 91 15:47:59 GMT
References: <6260006@otter.hpl.hp.com>
Reply-To: freeman@cleo.UUCP (Jay R. Freeman)
Organization: MasPar Computer Corporation, Sunnyvale, CA
Lines: 58

In article <6260006@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight) write\
s:
>I've been reading the most recent draft standard I've got (Nov89) and can't
>determine the answer to the following question.  When a port is garbage
>collected, is it automatically closed on your behalf?  Also, when a port is
>created, will every attempt (including garbage-collection) be made to free
>unused ports?
 
In Pixie Scheme (Macintosh Shareware) the heap object for a "port" is a
tagged pointer to another heap object that contains more information.  Thus
if you do
 
(define foo (open-output-file "stuff"))
(define bar foo)
 
then foo and bar will connect to the same file, so that alternate
writes to foo and bar will appear in that file in alternating sequence.
 
The unnamed "other heap object" contains, among other things, a
pointer into a table of non-heap data structures that contain the real
definition, status and so forth for each open port (Pixie Scheme
imposes a fixed limit on how many ports may be open at once, so a
non-heap table is reasonable), and which also contains a back pointer
to the (unique) heap object which referenced it.  On garbage
collection (Pixie Scheme uses two heap spaces with a variant on
mark-and-copy), Pixie Scheme updates each back pointer appropriately.
After the copy, Pixie Scheme looks through the non-heap table of ports
to see which ones have had their back pointers updated to point into
the new space.  The others are garbage, and are closed if still open.
 
Thus in the example given, if "foo" becomes garbage but "bar" is not,
then the heap structure associated with it will still have one pointer
to it from non-garbage (bar), so that heap structure will be non-garbage,
so it will get copied to new space, so its back pointer in non-heap
will be updated to point to new space, so the garbage collector will
know not to close the port.  But if foo and bar are both garbaged,
then the heap structure will not be copied, so its back pointer will
still point into old space, so the garbage collector will close the
port if the user has not done so.
 
The implementation of "open-output-file", etc., knows to look through
the table of non-heap port data structures for one which is not in
use, and fails if there are none.  At the moment, these implementation
routines do not force a garbage-collection if there are no ports free,
though they could be made to do so, and probably I will get around to
making that happen some day.  (I haven't done so merely because it is
clumsy to force garbage collection from any place other than the
memory allocator in my particular Scheme implementation, not because
it is a bad idea.)
 
 
I have no idea how other implementations do it, and would be curious
myself about the answers.
 
                                         -- Jay Freeman
 
 
          <canonical disclaimer -- I speak only for myself>