[MLton-user] Feature request: MLton.Finalizable

[John Reppy]

On Jun 2, 2008, at 7:05 PM, Matthew Fluet wrote:

> On Mon, 2 Jun 2008, John Reppy wrote:
>> I'm using finalization as a backstop for explicit management
>> of resources (e.g., textures and shaders).  I typically use the type
>>
>> 	Int32.int option ref MLton.Finalizable.t
>>
>> to represent these resources and set the ref to NONE when it
>> has been explicitly deallocated.
>
> Any reason not to simply let finalization take care of  
> deallocation?  I guess if you have limited resources, you might want  
> to proactively release them.

The lag of waiting for GC could cause performance problems or even  
prevent code from
working.  I don't think that finalization will every be a substitute  
for explicit
management of system resources, but it is a useful failstop.  I may  
even have my
finalizers print a warning message, since failure to deallocate unused  
resources is
a bug.

>
>
>> I could streamline this
>> process with the addition of the following two operations to
>> the Finalizable structure:
>>
>>      (* remove all finalization functions from the object *)
>> 	 val cancelFinalizers : 'a t -> unit
>>
>>      (* change the state of the finalized object *)
>> 	 val update ('a t * 'a) -> unit
>
> Why would you need both?
>
...

Strictly speaking, I don't need either, but the update is more  
important, since we want
to catch attempts to use a resource after it has been deleted.   
Removing the finalizers
means that the finalizer can be a bit simpler, but is less important.   
Unfortunately,
as you point out below, update is not attainable with the current  
implementation of
Finalizable.

>
>
>> The implementation is straightforward:
>>
>> 	fun cancelFinalizers (T{finalizers, ...}) = finalizers := []
>>
>> 	fun update (T{value, ...}, x) = value := x
>>
>> Any chance of getting these added to MLton?
>
> Your 'update' function doesn't work with the Finalizable  
> implementation. The finalization functions are invoked on the  
> original value v used to construct the finalizable value.  The  
> closure passed off to the GC handler can't be closed over the  
> reference cell pointed to by the weak pointer, else the reference  
> cell would always be live.

That's a more serious objection, since I'm trying to avoid the extra  
level of indirection :(.
I guess that this could be made to work if finalization was  
implemented as a functor with
the finalization functions as functor arguments.  I guess I'll just  
stick with my current
implementation then.

	- John