Finalizers strike back

[George Russell]

Fergus Henderson wrote:
> 
> On 11-Oct-2002, George Russell <ger at tzi.de> wrote:
> > I think we should remember that the FFI standard has to address various
> > audiences
> > (1) those who want to implement portable code in just FFI + Haskell98.
> > This group does not have access to functions for conveniently manipulating
> > mutable state, therefore Alastair's problem with IORefs will not be a problem
> > for them. However Haskell inside finalizers will at any rate not harm them
> 
> This argument is invalid, because those who want to implement portable
> code in just Haskel98 + FFI will very quickly use the FFI to implement
> IORefs or something similar.

Yes, I suppose they could also hack it up in Haskell98 by writing values to files
or by using IO.hGetBuffering and IO.hSetBuffering.  I really think there are limits 
to the extent we need to protect hackers from their own ingenuity.  

> 
> > Consider someone who, say, calls out from Haskell to Java (to do funny
> > graphics, say) and writes a finalizer which calls Java code.  At the same time, they
> > also want to do some completely separate pure computation in Haskell, which is made
> > available to Java.  Since Java at least does have preemptive concurrency, while
> > it is running at all, it is perfectly possible that Java will call the Haskell computation
> > while the Java finalizer is running.  You want a license to make the roof fall in at this
> > point; I don't think you should have it.
> 
> If you have a non-thread-safe Haskell implementation, and you try to
> call it from two different threads without protecting this somehow,
> then the roof *will* fall in at least some of the time.  This follows
> directly from the definition of "non-thread-safe".
> 
> So you want to disallow non-thread-safe Haskell implementations from
> supporting the FFI?

I agree this is a problem, though I don't think there is much we can do about it.  However
the problem I describe arises even without multiple operating system threads, for example if
both Haskell and Java implement concurrency using "green threads" (as I think Sun's Java
implementation used to call them), so exactly as GHC and Hugs does it, with just one
OS thread doing its own scheduling.  Where both Hugs and Java are running in such a situation,
they would presumably all be running in the same thread, with only one running at any one time.