Finalizers: the Legend that Won't Die
Manuel wrote (snipped)
I have just read Hans Boehm's POPL paper on finalizers. His suggestion for the use of finalizers in single-threaded systems is to provide a `runFinalizers' routine, instead of relying on the asynchronous execution that, as established, requires support for concurrency. I am not sure whether we have given this option really serious consideration. I can only see one problem with this. Suppose you have the following sequence of events:
let x = seq (unsafePerformIO runFinalizers) y finalizer = [... something involving x ...] [... attach finalizer to something ..] [... something becomes free, putting finalizer on the to-be-done list ...] [.., computation requiring x ...] Then during the computation of x the following things are liable to happen: (1) Evaluation of x begins. x is blackholed. (2) runFinalizers is invoked. (3) "finalizer" is begun. (4) finalizer needs value of x. Ooops, what do we do now? Is it safe to run runFinalizers anywhere except in the main IO trunk? Otherwise you always have the risk of coming a cropper on blackholed values, don't you? George
George Russell <ger@tzi.de> writes:
Is it safe to run runFinalizers anywhere except in the main IO trunk?
This is the first question that occurred to me too.
let x = seq (unsafePerformIO runFinalizers) y finalizer = [... something involving x ...]
Otherwise you always have the risk of coming a cropper on blackholed values, don't you?
But isn't this just the same as any other program that contains a blackhole fault? i.e. the program is logically incorrect. What is more, the runtime system will probably tell you "Blackhole detected!" or "<<loop>>" or something, which is helpful. So I don't see why this sort of program would become particularly more common than it currently is, if the runFinalizers() procedure is added to the FFI spec. Regards, Malcolm
participants (2)
-
George Russell -
Malcolm Wallace