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

On Sat, Feb 7, 2009 at 1:28 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

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

I think in most cases custodian might indeed be enough.  But suppose that
the code needs to do some additional clean up during the shutdown phrase.  A
contrived (or maybe not so much) example: when we start a database
connection, we set the lock on the database file (which is its own separate
file), and when we close the database connection, we also have to ensure
that we delete the lock so the state of the database is clean.

In such a situation, the additional clean up requires a separate procedure
call that needs to be called during the shutdown phase.  I am not sure how
to do such a setup with using custodian.  That's why I asked whether there
is a hook that can clean up such objects.


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

call-with-* are for auto/local variable management, but I am thinking about
longer lived objects, analogue would be C++ object managed through smart
pointers such as the boost library.  For example, there might be a module
that provides a set of functions as its interface, but the module hides the
fact that these functions uses a database connection (supposedly we can swap
out the module so the client should not be aware that there is a database
connection).  In such situation it would be nice to have the module that
hides the implementation detail to manage the destruction of the object once
the module goes out of the scope.

Thanks,
yc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20090207/852c7eff/attachment.html>