On Sat, Feb 7, 2009 at 3:48 PM, Carl Eastlund <carl.eastlund at gmail.com> wrote:
> On Sat, Feb 7, 2009 at 2:58 PM, YC <yinso.chen at gmail.com> wrote:
>> On Sat, Feb 7, 2009 at 11:50 AM, Carl Eastlund <carl.eastlund at gmail.com>
>> wrote:
>>>>>> > 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. 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.
>>>> What is the hook to provide GC with such knowledge to close the database
>> handles if I need to implement my own database connection? My failure to
>> find such a hook misled me to think GC can't be made handle external
>> resources gracefully.
>>>> Is it the will executor? It seems that will isn't called by GC, though.
>> It is the will executor. It is not automatically called by GC because
> that leads to unpredictable execution order. It is, however, enabled
> by GC -- that is, the garbage collector determines when a will
> executor is ready to be run. If you schedule the will executor (put
> calls in your program to check when it is ready to run, or spawn a
> thread to run it whenever it's available), though, it will run when a
> value is ready to be garbage collected.
As a technical aside about my second sentence above, I don't mean to
imply that the current will executor mechanism has totally predictable
execution order... just that the current scheme gives a little more
control over how will executors interleave with the rest of the
program. Section 15.3 of the PLT Scheme reference gives more detail.
--
Carl Eastlund