Fail: <<loop>> from finalizers and stuff

[Simon Marlow]

On 04 July 2004 23:54, Sven Moritz Hallberg wrote:

> Dear Foreign Function Interface,
> 
> why does a program like the following fail with a "<<loop>>" exception
> (using GHC 6.2 on MacOS X)?
> 
> -----snip-----
> import Foreign
> 
> main =
> 	do
> 	f	<- mkFinPtr finalizer
> 	fp	<- newForeignPtr f nullPtr
> 	putStrLn "Hello World"
> 
> finalizer ptr = putStrLn ("Finalize "++show ptr++".")
> 
> foreign import ccall "wrapper"
> 	mkFinPtr :: (Ptr () -> IO ()) -> IO (FinalizerPtr ())
> -----snap-----

This is a FAQ, but you could be forgiven because the latest version of
the FAQ on the web site doesn't have this entry yet.  Here it is:

    <varlistentry>
      <term>I can't get finalizers to work properly.  My program
      sometimes just prints
      <literal>&lt;&lt;loop&gt;&gt;</literal>.</term>
      
      <listitem>
	<para>Chances are that your program is trying to write a
	message to <literal>stdout</literal> or
	<literal>stderr</literal> in the finalizer.  Handles have
	finalizers themselves, and since finalizers don't keep other
	finalized values alive, the <literal>stdout</literal> and
	<literal>stderr</literal> Handles may be finalized before your
	finalizer runs.  If this happens, your finalizer will block on
	the handle, and probably end up receiving a
	<literal>NonTermination</literal> exception (which is printed
	as <literal>&lt;&lt;loop&gt;&gt;</literal>).</para>
      </listitem>
    </varlistentry>

> Also, does the use of a "wrapper" import constitute a callback from C
> in the sense of the following statement?
> 
> 	"Whether a finalizer may call back into the Haskell system is
system
> dependent. Portable code may not rely on such callbacks."
> 
> I.e. is the above code non-portable?

Yes.

> Why is the ForeignPtr interface constrained to finalizers that are
> FunPtrs at all? I want to touch a ForeignPtr from another's finalizer
> to satisfy a liveness dependency (as suggested in the spec). What is
> the best way to do this?

Good point.  That comment in the spec is left over from when we had
Haskell finalizers in the standard, and doesn't make sense any more.
(Manuel - are you keeping errata somewhere?  Or is someone else?)

Doing this is now non-portable because some Haskell systems don't
support calling back into Haskell from a finalizer.  If you're committed
to being non-portable, then the right way is to use the
Foreign.Concurrent interface instead of the wrapper trick you use above.

Cheers,
	Simon