[MLton] adding synchronous finalizers

[Stephen Weeks]

> I  guess that it makes sense that one would still want to have finalizers (or
> signals) only done when checking but  still  have  multiple  threads,  so  it
> doesn't  sound  like  it  should  be  an  error if a signal handler returns a
> different thread.

If I understand what you're saying, you're saying that one may want to
have synchronous finalizers in multi-threaded programs and in programs
that handle signals asynchronously.  Is that right?

If so, then it seems like my original proposal to have a separate
function for finalizers

	val MLton.Finalizable.runFinalizers: unit -> unit

is the way to go.

The point is that if signal handler returns a different thread, then
you are by definition treating signals asynchronously.

> As to finalizers vs. signals  being  done  differently  (one  automatic,  one
> polled),  that  really does look like setting some ref to what should be done
> automatically makes sense.

Again, if I understand what you're saying, you're arguing for two
refs, one for finalizers and one for signal handlers (or possibly per
signal?), that control whether or not the signal is handled
asynchronously.  Or are you simply agreeing that one bool ref for
finalizers is enough?

I still don't understand what your proposal is for synchronous signal
handlers.