addForeignPtrFinalizer

[Alastair Reid]

> To be honest, I don't understand why you are so opposed to this.

I don't want to encourage people to write code which can't work on
Hugs and NHC.  If we provide Haskell finalizers with the restriction
that they can only call C code, users will go ahead and write
finalizers which call arbitrary Haskell code and then the code won't
work with Hugs and NHC - portability is decreased. 


So, maybe we should make Haskell finalizers work as well on NHC and
Hugs as they do on GHC?  What would it take to do this?

I believe it would take a massive effort to make Haskell finalizers
work both for existing systems and new systems because:

1) Being able to write finalizers in Haskell is pointless
   unless they can safely modify shared state.  (Worse, it is
   dangerous because unsafely modifying shared state leads to 
   race conditions which are unbelievably hard to track down.
   Much harder than the debugging sessions that George envisages.)

   Any useful form of Haskell finalizer requires the provision of
   blocking synchronization which will require a complete rewrite of
   the runtime system and potentially decrease portability.


2) None of our Haskell primitives are intended for a multi-threaded
   environment.  Consider a pair of primitives that share a common
   data structure like hClose and open.  What happens if a finalizer
   calls hClose while the main thread is in the middle of creating a
   file?  It probably works ok but we know from experience with
   writing multithreaded code that the only way to be sure is to look
   at the code.

   In fact, we have to check it and every other Haskell primitive that
   affects some shared structure.  In other words, we have to vet a
   lot of code to see if it can be used in a single-threaded way and
   modify offending code by moving any allocations to the start or end
   of the modifications.

   We also have to keep this in mind every time we modify the 
   runtime system.

In short, we have to do most of the work of making Hugs support
preemptive concurrency: we have to provide blocking synchronization
and we have to rewrite our code as though a preemption could happen 
on any heap allocation.

Plus, it makes maintenance harder because it makes it easy to
introduce race conditions.


> Why not find out whether SimonM's patch works?  If it does, the
> problem is solved, we can use the nicer definition, and everybody is
> happy.

As you know, testing for race conditions is very hard.  We could test
and test and not see a problem and then a week into the release we get
a bug report.  But, worse, the report also says that the bug goes away
if they make some small change to their code.  The change will not
actually fix the problem, it will just change the allocation/GC
pattern so that the problem doesn't show up in the test.


--
Alastair Reid                 alastair at reid-consulting-uk.ltd.uk  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/