🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.clos
Article #368

Re: destructors in CLOS?

#368
From: Creon C. Levit
Date: Thu, 20 Dec 1990 19:22
65 lines
3073 bytes
Here is one of the responses to my query, mailed directly to me and
not to comp.lang.clos, that may be of interest to the group.  I also
mention the application that I and some other are working on, and how I
feel could benefit from destructors methods, of "finanize-instance"
methods. 

Arun Welch wrote:

   Right now, no, at least not portably. At this point you can't even
   call a function on any object before it gets GC'd, let alone
   instances. Franz has proposed finalize-instance to handle such a
   case, and JonL and I talked about it at AAAI, but we had a hard
   time coming up with any examples for needing it that weren't
   contrived, so if you've got an honest reason for it, we'd love to
   hear what it is. In general, we were worried about the extra work
   that the GC would have to do, and what sort of performance hit it
   would incur. 


An example, not contrived, though perhaps implementable well enough using the
techniques barmar mentioned, involves using CLOS on a silicon graphics
IRIS (380 VGX).  The operating system on the iris is a version of unix
called IRIX that has several features important for scientific
visualization - our problem domain.  The features of relevance are:

1. Mapped files - there is a system call which maps files into your
address space.  No need to read the data - it gets paged in when you
reference it (a speed win).  There is also no need to malloc space for
it, and it does not contribute to the size of your swappable image (a
space win).  Standard stuff, I know.  We make extensive use of mapped
files when visualizing large (read-only) data sets.

You are supposed to call unmap() when you are done with the mapped file,
since the system can only support a finite number of these mapped
files at any time.  

2. Graphics library windows.  Should atomatically close soon after
they become unreferenced, returning their descriptors to the system
for reuse, and freeing valuable screen space.

3. Yes, Streams.

Any instance invovling 1,2 or 3 seems a good candidate for a
finalize-instance method.



PS - Is anyone extending CLOS for multiprocessing?  The IRIS has
eight processors and OS support for multiple theads w/shared memory.
It would be wonderful to get at it in a standard way.


 

--
Creon Levit

mail stop T045-1
NASA Ames Research Center
Moffett Field, California 94035

(415)-604-4403

creon@nas.nasa.gov  (Internet)
Technical Details
Message-ID: <CREON.90Dec20112237@wk39.nas.nasa.gov>
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!agate!shelby!eos!data.nas.nasa.gov!data!creon
References: <CREON.90Dec18151709@wk39.nas.nasa.gov> <GUMBY.90Dec19092440@Cygnus.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!agate!shelby!eos!data.nas.nasa.gov!data!creon
From: creon@nas.nasa.gov (Creon C. Levit)
Newsgroups: comp.lang.clos
Subject: Re: destructors in CLOS?
Message-ID: <CREON.90Dec20112237@wk39.nas.nasa.gov>
Date: 20 Dec 90 19:22:37 GMT
References: <CREON.90Dec18151709@wk39.nas.nasa.gov>
 <GUMBY.90Dec19092440@Cygnus.COM>
Sender: news@nas.nasa.gov
Reply-To: creon@nas.nasa.gov
Organization: Applied Research Office, NASA Ames Research Center
Lines: 65
In-Reply-To: gumby@Cygnus.COM's message of 19 Dec 90 17:24:40 GMT