Proposed change to ForeignPtr

[George Russell]

Alastair Reid wrote:
[snip]
> What you're asking Hugs and NHC to do is: add a function to a list
> whenever you have a finalizer to run; make sure the interpreter will
> test that bit whenever it is in a position to perform a context
> switch.
Am I really asking that much?  In that paper you wrote you already propose
that the Haskell system implement functions which tell C when it enters GC and
when it leaves GC.  So what it seems you need is for this to set a flag so that
(1) When the (Foogle) finalizer runs, it runs normally if this flag is unset (no GC is
running, so presumably safe).  Otherwise add the action to a queue.
(2) When Haskell leaves GC it checks the queue and runs any pending actions,
backing up if it's necessary to do so.

The flag and queue need to be atomically accessed, but since (for Hugs and NHC)
you are assuming only one OS thread, that should be enough.  You don't for example have to
worry about exported functions being called absolutely everywhere.
[snip]
> The cost is going over all data structures in the system making sure
> that operations on them are suitably atomic.
[snip]
If something like that would work, the cost during normal operation would only be
the cost of setting and clearing the flag at the start and end of GC, and checking the
queue at the end of GHC. 

I'm sorry, it's frightfully arrogant of me to argue over details of Haskell compilers with
their implementors, but what else can I do here?  Anyway the point is a general one; can we implement
FFI without needing the whole machinery of concurrency?  
> > If it's really impossible for NHC or Hugs to implement this, I think
> > I would still rather it was left to the NHC and Hugs documentation
> > to admit that exported Haskell functions basically don't work in
> > some circumstances, rather than to the GHC documentation to say that
> > actually they do.
> 
> It's a matter of taste how you do these things.

If we take it that there is no way for a finalizer to call functions exported from NHC or Hugs,
my personal preference would be to regard this as an undesirable implementation glitch which
should be documented in the NHC and Hugs documentation.  This would then be something users of
the FFI with NHC and Hugs have to worry about, rather than users of the FFI in general.  I don't
think it makes the FFI worthless for NHC and Hugs, any more than the recent discovery that IO is
not really a monad on most implementations makes the Haskell standard worthless.