[Haskell-cafe] Re: Are handles garbage-collected?

[oleg at pobox.com]

Simon Marlow wrote:
> I've been wondering whether having a more synchronous kind of
> finalizer would be a good thing.

Hans Boehm in his POPL2003 paper "Destructors, Finalizers, and
Synchronization" persuasively argued that finalizers _must_ be
asynchronous. That assertion is the title of Section 3.5 of the paper.


Peter Simons wrote:

> input -> iodriver --> connection handler --+
>            | /|\                            |
>  output <--+  +-----------------------------+
>                        (Event, State)
> ...
> The I/O driver is a StateT monad which calls the (various)
> connection handlers every time new input is available from
> the network. The handlers are StateT monads, too, and their
> respective state is stored in the I/O driver's state when
> they return.
> ...
> The only solution I would know is to put the entire state of
> the connection handler into an MVar, so that any changes to
> it are immediate for the I/O driver. But that approach feels
> like overkill to me.


It seems you don't need to store the whole state in MVar: it's enough
to store a `clean-up' action. Suppose there exists an MVar known to
both a connection handler and the iodriver. The type of MVar's value
is Maybe (IO ()). When the connection handler opens a Handle, it
places a Just action that will close the handle. If the connection
handler makes it to the end without getting an exception, it, right
before returning to the iodriver, replaces that cleanup action with
Nothing. The iodriver, upon getting control back, checks the MVar and
executes whatever action is outstanding. The action can refer to any
context it needs for the clean-up.

Come to think of it, perhaps MVar is overkill. From your description,
it seems that each connection handle has its own private piece of
state inside the iodriver state. Perhaps it is not so much to ask to
add an IORef (Maybe (IO ())) to that state. The iodriver will check
that IORef upon getting control back from the control handler; Or the
driver can scan all these IORefs upon receiving an event, an
exception, etc.

Perhaps a more general approach is a special Handle leasing
component. Can we assume that a connection handler has a specific ID?
Can we assume that all alive connection handlers can be enumerated (it
seems so from the above description: iodriver is aware of all alive
connection handlers). If these assumptions hold, we can introduce one
level of indirection. Whenever a connection handler needs a Handle, it
applies to the Lord of Handles (LoH), passing its own id and the file
name. The LoH gives an id of a handle (or the handle itself). The LoH
also stores the allocated Handle and the component ID in its
tables. From time to time (or on certain events) the LoH checks all
the open handles to see if the corresponding connection handlers are
still alive.