Path: 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: Date: 20 Dec 90 19:22:37 GMT References: 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 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)