[MLton] adding synchronous finalizers
Stephen Weeks
MLton@mlton.org
Thu, 30 Sep 2004 11:50:16 -0700
> 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.