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

At Sat, 7 Feb 2009 14:50:11 -0500, Carl Eastlund wrote:
> On Sat, Feb 7, 2009 at 2:42 PM, YC <yinso.chen at gmail.com> wrote:
> > On Sat, Feb 7, 2009 at 10:46 AM, Matthias Felleisen <matthias at ccs.neu.edu> 
> wrote:
> >>
> >> And struct provides basic inheritance, so what's missing is polymorphism,
> >> but that's possible to achieve if the struct themselves carry the functions
> >> that they need to call. Also I miss the destructor and explicit finalize.
> >> Those comes in very handy for external resource management.
> >>
> >> GC.
> >
> > I am probably missing the point here, but I think GC doesn't help with
> > closing file handles or database connections (at least *safely*), no?
> >
> > Thanks,
> > yc
> 
> The PLT Scheme garbage collector does close file handles.

No, file handles are not automatically closed when the associated port
is unreachable.

> 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.

Imagine that PLT Scheme did close file handles when they become
inaccessible. Programmers will then write programs that depend on it.
To keep the program working reliably, The runtime system would have to
trigger a GC when it fails in an attempt to open a new file handle. For
the sake of argument, suppose we get that right.

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.)


File handles are registered with a custodian, as Shriram alluded. If a
DB connection is implemented through an FFI binding to some library,
then each DB connection also should be registered with the current
custodian. If it's built on file descriptors, TCP connections, or other
things that are already registered with the custodian, then probably
nothing more is needed.


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.


Matthew