> [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 implemented. > 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 names. Sigh... 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 void hs_perform_gc(void); 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. -- Alastair _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi