Re: ForeignPtr-related signatures
Malcolm Wallace wrote:
[...] there was considerable sympathy for using new names for the C-finaliser-only functions, preferably incorporating the word "unsafe" [...]
I'd really prefer that, too. Simon Marlow wrote:
GHC 5.04.2 won't adopt any library changes, as it's only a patchlevel release (we don't make API changes between patchlevels, only major releases).
That's what I expected. Would it be possible to include the new functions in 5.04.2? OK, that's an API change, too, but simple additions are rather harmless. If we don't include this stuff now, there is no useful common ForeignObj API for GHC/Hugs/NHC in the near future.
[...] Also still unresolved is what to do about atomicModifyIORef and friends, BTW.
I remember atomicModifyIORef, but what are its "friends" exactly? PVars have died, IIRC, and some cunning constraints on the execution order of finalizers were rejected, too. Cheers, S.
On Mon, Nov 18, 2002 at 11:42:41AM +0100, Sven Panne wrote:
I remember atomicModifyIORef, but what are its "friends" exactly? PVars have died, IIRC, and some cunning constraints on the execution order of finalizers were rejected, too.
Do you mean dependencies between ForeignPtrs? I don't think the people who need them have given up. But I certainly hope that the execution order of finalizers on a single ForeignPtr is specified, and I think I saw SimonM agreeing to it. At the minimum it is necessary to specify that any finalizer added to a ForeignPtr created with mallocForeignPtr runs before the memory is deallocated.
participants (2)
-
Ross Paterson -
Sven Panne