The Death of Finalizers
alastair at reid-consulting-uk.ltd.uk
Mon Oct 21 20:06:53 EDT 2002
> [snip] How sad. It's an unfortunate hole in the specification and I
> hope someone will come up with a way of fixing it someday.
I don't think it'll happen until preemptive concurrency is more widely
> In the meantime, I'm glad we have got a new function
> atomicModifyIORef which I for one will use, when it gets into GHC's
> regular release. It's really nice that we can use laziness to
> safely update a mutable value without blocking. Another nail in the
> coffin for Standard ML.
Do we still have atomicModifyIORef?
I don't know that there's that much point now that Haskell finalizers
are gone. I don't have a strong objection (esp. since it seems every
implementation now has it) but it doesn't seem so necessary now.
> I think the addForeignFinalizer function or whatever it is should
> nevertheless be renamed to addUnsafeForeignFinalizer (and likewise
> for newForeignObject).
I see some sense in that argument but:
1) I don't especially like that the only standard way of doing finalizers
is labelled 'unsafe'.
2) We started cutting release candidates for Hugs yesterday using the old
Again, no strong objection but I'd do it differently.
> Also I suppose Alastair's hs_freeStablePtr function which allows you
> to do it from C, or whatever, will have to be added.
I've just added
void hs_free_stable_ptr(HsStablePtr x);
to Hugs in the hope that it will make it into the next release candidate
The capitalization change is for consistency with
and I hope it will be what we put into the FFI report.
> I hope Alastair will forgive me for engaging him in such a lengthy
> argument, when he turns out to have been right all along.
I wish I'd come up with convincing arguments faster.
More information about the FFI