[plt-scheme] Re: [plt-edu] Re: animation projects, video-game and not

>> A database
>> library certainly could, and should, use the garbage collector to
>> close connections.  I don't know which ones do, but that's only my own
>> inexperience with Scheme database libraries.  In both cases, GC
>> doesn't preclude the option to manually close a connection earlier --
>> but GC makes that into an optimization rather than a necessity, for
>> most purposes.
>
> GC is a poor fit for scarce resources like file handles. It's partly a
> mismatch between scarce resources and the plentiful resource of memory,
> but OS and library limitations are the main factor.

A better example is an externally managed data structure.  For
instance, when we linked to decision diagrams -- which are managed
internally in a library, through reference counts -- we used wills to
inform the library that there were no more references from Scheme.
That is, all of Scheme is a ++ ref, and dropping all references from
Scheme is a -- ref.  This is a good fit for wills, because the
granularity is the same; the wills are just massaging over differences
in storage and management strategy.

> Now suppose that you want to use an external library that happens to
> open some configuration file internally. That library isn't going to
> know that it should force a GC if opening the configuration file fails,
> so making the library work nicely in a GCed-file-handle world is going
> to be a big pain, at best. (This is also why it would be difficult to
> get right within the run-time system.)

Isn't it worse?  Usually, external libraries are not written with the
assumption that files close without their say-so.  That means a
perverse bit of code might allocate a file, temporarily lose a direct
reference to it, but re-acquire reference through some system
mechanism (such as referring to the file pointer).  [To put it
differently, reachability might involve the OSes internal data
structures, which are generally not considered for tracing.]  Such a
library would now behave faultily.

> Meanwhile, wouldn't the closest analogue to automatic C++ init/destruct
> for a block be `call-with-...' functions, such as
> `call-with-input-file'? Those use `dynamic-wind' to ensure that the
> file is explicitly closed when control leaves the `call-with-...'
> invocation.

Indeed, the Wikipedia article mentions UNWIND-PROTECT.

Shriram