Pointers in Slate.

[Brian T. Rice]

Todd Fleming <todd at flemingcnc.com> said:

> Brian Rice wrote:
> > About finalizers, yes. Resources should be pushed into a collection 
> > whose elements are then re-initialized (mostly opened) on the next 
> > startup, as well as of course being closed on shutting down.
> 
> I was thinking about it a little differently. An open file does no good 
> if it isn't being used by something. The closest way I know if to model 
> "use" is that something is pointing to it. So, if nothing is pointing at 
> an open file object, it would be nice if the GC eventually closes the file.
> 
> Example: a read stream is opened on a file. The read stream is given to 
> something that uses read streams, but doesn't know that it needs to 
> close the stream when it's done. Instead it just "forgets" the stream 
> and the GC eventually calls a finallizer which closes the file.

Doh! I was not really thinking about the important finalizer situation, but 
what my immediate goals were; you caught me in a non-answer. Yes, we're 
interested in proper automatic finalizers along with the ephemeron idea for 
using weak references along with them (implemented in VisualWorks and Squeak 
and Dolphin I believe).

> There are some problems with this. Some OS's (Linux) limit how many file 
> descriptors a process may have open. When the limit is reached, you 
> could trigger a full GC and try again. Unfortunately, Linux also has a 
> limit on how many file descriptors are open across the entire system, so 
> this would mean the process doesn't play well with others. Other OS's 
> (Windows) don't have an open-file limit (other than memory of course), 
> but keep locks on the file until it is closed. You can use non-exclusive 
> locks in Windows, but most applications use exclusive locks, so they 
> would be prevented from opening a file that is still hanging around in 
> Slate unused.

Yeah, others have reminded us of this as well.

> There are probably other external resources which don't have these 
> problems and would benifit from not having to manually free them.

It will be interesting if there are. But yes the mechanism should be general; 
I think the ephemeron idea has worked well enough and simply enough, but Lee 
may have other ideas or constraints in mind.