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

1. I am aware of the file and db example. I just explained all this  
to a visitor on friday (who requested gc'ed file handles).

2. YC's original message alluded to memory, which is usually not  
subject to special treatment but gc'ed.

3. And yes, I know about external resource management. I write my  
programs with call-with- and custodians.

-- Matthias





On Feb 7, 2009, at 4:38 PM, Shriram Krishnamurthi wrote:

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