The Revenge of Finalizers

Alastair Reid alastair at reid-consulting-uk.ltd.uk
Wed Oct 16 12:55:09 EDT 2002


> (2) blockFinalizers looks fine for Hugs and NHC which only have a
> single-thread model, but it looks tricky in general where [...]

Ah, I see what you mean.  

I'd kinda hardwired into the definition the assumption that finalizers
run at higher priority than other threads and that there's a single
execution thread.

I'd hoped that blockFinalizers would be useful for defining other
primitives but since it won't even work for GHC, I agree that PVar
will meet most of our needs.  (An even simpler design might be to
extend our IORef implementations with 'atomicallyModifyIORef'.)

So, is this a design that we could agree on?  

It seems a reasonable question to ask is whether either PVars or
atomicallyModifyIORef could be used instead of MVars in existing
concurrent code.  If yes, then it seems likely that we can make our
libraries Finalizer-safe.  If no, it'll probably give us some clues as
to what is missing and we can think about whether we'd miss them.

A



More information about the FFI mailing list