The Revenge of Finalizers

[Simon Marlow]

> > So is it just that there are a small number of places where it is
> > unsafe to invoke IO from a primitive,  
> 
> It is unsafe to invoke IO from a prim _in the middle of_ manipulating
> a data structure manipulated by IO operations unless the data
> structure is designed to allow that nested use.  Trivial example:
> using a counter instead of a bool to record whether finalizers are
> blocked makes nested calls ok (at least as far as that particular data
> structure is concerned).
> 
> (It would be unsafe to invoke eval from prims which manipulate data
> structures in pure code except that we took care when writing the code
> to allow for that since most of the prims invoke eval.)
> 
> > [...] Can we easily identify which are the unsafe places 
> and fix them?
> 
> Look at all prims with types in IO.  Look at what data structures they
> touch.  Check if there are accesses to that data structure 'both
> sides' of a call to eval (there may be a few functions which invoke
> eval so watch for them).  Check if any such accesses break data
> structure invariants.

Since this can affect Hugs as it stands (when you use unsafePerformIO),
would you mind taking a look?

> Now repeat for library code that we ship with Hugs.  Data structures
> of interest will be those constructed with IORefs and things built
> from them (this includes MVars since Hugs implements MVars using
> IORefs).

The following libraries in fptools/libraries use IORefs and might be
unsafe:  System.Random and Data.Dynamic.  Hugs has its own versions of
these libraries that also use IORef in the same way.  For GHC, we really
ought to fix these to use MVars, since they're unsafe already.  For
Hugs, I don't think it would be a complete disaster if in the errata you
say that Data.Dynamic and System.Random can't be used from finalizers.

Cheers,
	Simon