Finalizable contexts

[pclayton]

Given many finalizers that use a common resource, there does not appear to be a way to run the finalizers as a group allowing the common resource to be used once. If use of the resource has an overhead, using the resource independently in each finalizer is inefficient. For example, the finalizers may need to obtain a common lock. In my case, the finalizers need to be scheduled in (a callback from) the application's main loop.

To provide general support for this I am using the following interface:

signature CONTEXT_FINALIZABLE =
  sig
    include FINALIZABLE

    structure Context :
      sig
        type t
        val new : unit -> t

        type marshaler = (unit -> unit) -> unit
        val setMarshaler : t -> marshaler option -> unit
        val finalize : t -> marshaler * (unit -> unit) -> bool
      end

    val newInContext : Context.t -> 'a -> 'a t
  end

With this signature, a finalizable value is created in a context to allow its finalizers to be run with finalizers of other finalizable values created in the same context.

• A context is created using Context.new ().
• A finalizable value is created from a value x in a context c by newInContext c x.
• A group of finalizers that are ready to be run are passed to a marshaler, a function that runs them.
• A marshaler m that is registered using Context.setMarshaler c (SOME m) will be used to run a group of finalizers of finalizable values in the context c asynchronously following garbage collection.
• The finalizers of finalizable values in a context c are not run asynchronously if no marshaler is set using Context.setMarshaler. A marshaler m is applied to a function that runs these finalizers using Context.finalize c (m, doGC), where doGC is evaluated first, typically to perform garbage collection. The marshaler m is run synchronously. (Whether these finalizers are run synchronously depends on the marshaler m.) Finalizers of finalizable values not in a context are also run synchronously. The result is false only if no finalizers were run between doGC returning and Context.finalize returning, i.e. without any other execution, false indicates that evaluating Context.finalize c (m, doGC) again would have no effect. Using Context.finalize c (m1, doGC) when context c has a marshaler set using Context.setMarshaler c m2 will result in one of the marshalers m1 or m2 being used but which marshaler is implementation-defined. Context.finalize may be called where the argument doGC is the identity function in which case it performs synchronous finalization only.

This interface therefore allows mixing of synchronous and asynchronous finalizers.

My case was more specific as I just needed a context for each thread. For this, I am using the following interface, whose implementation is derived from an implementation of CONTEXT_FINALIZABLE:

signature THREAD_FINALIZABLE =
  sig
    include CONTEXT_FINALIZABLE

    structure Thread :
      sig
        type marshaler = (unit -> unit) -> unit
        val setMarshaler : marshaler option -> unit
        val finalize : marshaler * (unit -> unit) -> bool
      end

    val newInThread : 'a -> 'a t
  end

My MLton implementation assumes only one thread. Still, the distinction between new and newInThread is useful because the latter is used for finalization of C objects that are not thread-safe (for which the marshaler adds the finalizers to a callback from the main application loop).

[MatthewFluet]

I understand the idea. Given the other discussions going on about finalizers, I wonder again if the right solution is expose a few lower-level operations (which definitely belong in the MLton.Finalizable structure) upon which these kinds of libraries could be built, at which point we can consider whether any are sufficiently general-purpose to be brought into MLton.Finalizable.

It isn't clear to me why one would want Context.new: unit -> t and Context.setMarshaler: ((unit -> unit) -> unit) -> unit. Would it not make more sense to set the marshaler when the context is created? If a particular application really needed to dynamically change the marshaller, they could choose to pass in a closure that consults a ref. It also seems limiting for the contexts to be entirely opaque, particularly if they are acquiring a resource that should be available (and passed?) to the finalizers that are run in that context. I might expect something more like:

signature CONTEXT_FINALIZABLE =
  structure Context :
    sig
      type 'a t
      val new: (('c -> unit) -> unit) -> 'c t
    end
  type ('a, 'c) t
  val addFinalizer: ('a, 'c) t * ('a * 'c -> unit) -> unit
  val finalizeBefore: ('a, 'ca) t * ('b, 'cb) t -> unit
  val new: 'a * 'c Context.t -> ('a, 'c) t
  val touch: ('a, 'c) t -> unit
  val withValue: ('a, 'c) t * ('a -> 'b) -> 'b

and (uncontexted) finalizers would just be a specialization to a no-op context.

And it seems that this could be implemented upon a lower-level set of operations that simply allowed the mutator to create different queues of pending finalizers.