The Revenge of Finalizers

Alastair Reid alastair at reid-consulting-uk.ltd.uk
Tue Oct 15 16:32:25 EDT 2002


>> > So, are we now claiming that my patch *is* safe?  (Never mind
>> > about IORefs, I'm talking about the implementation itself).
>> 
>> No.

> Then I'm confused.  Allow me to quote your previous message:

>> Most calls to IO actions from primitives are safe and I believe
>> these ones are too.

> 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.

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).

--
Alastair




More information about the FFI mailing list