| I claim that the major thing that finalizers do is manipulate shared | state.
That is certainly true. If they were pure, you'd never know they'd run! | To get any benefit from writing finalizers in Haskell, I have to have | MVars which protect against finalizers. Nearly right, but not quite. You might write a Haskell finalizer that did lots of useful things (e.g. consulted a large pure data structure) before doing its state-mutation by calling C. | > And if they existed, everything would be fine, right? We could | > just use Haskell finalizers as we all want. Or am I missing | > something. | | Finalizers would have to be scheduled by the same scheduler as normal | threads. Yes. | The scheduler would need to prioritize finalizers over normal threads. Desirable but not necessary. The programmer cannot expect finalizers to run promptly (there is always lots of literature on the GC mailing list about this point). | Most of the cooperative concurrency implementation is written in | Haskell. That would have to be rewritten in C to make the operations | atomic wrt garbage collection. No, I disagree with this. When GC runs, the finalizers can be put in the ready queue. After GC completes, the thread that was interrupted by GC continues. So a thread switch takes place ONLY when the thread yields, as now. (Again, promptness is not a reqt. If the thread never yields, the finaliser will never run. That is 100% ok. You absolutely should not RELY on finalizers. So the question before the house is to choose between: A) Haskell finalizers: flexible; continue to be what we want when we have concurrency; but if your impl does not support MVars you have to call C to do state mutation. B) C finalizers: less flexible; GHC will have (A) anyway; but arguably one less trap for the unwary. I still prefer (A), albeit not unto death, because (i) I believe that supporting MVars in Hugs is not as hard as you think. (I'm agnostic about NHC.) (ii) Less incompatibility... (i.e. programs that use GHC extensions that won't run on Hugs) (iii) Moves in the direction we will ultimately want to go. It seems bizarre to write finalizers in a different language! Simon _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
