[HOpenGL] news on FFI?

[Simon Marlow]

> > I would like to know if that will help to solve that=20
> "uncaught exception
> > problem" when leaving HOpenGL programs.
>=20
> A strictly conforming implementation shouldn't have that problem, see:
>=20
>   http://haskell.org/pipermail/ffi/2002-January/000436.html
>
> I know that Simon "RTS" Marlow :-) is on this list,

what... who.. me? :-}

> so perhaps he could answer
> the question when GHC is changed this way...

Ok, the problem as we all know is that System.exitWith now raises an
exception rather than simply terminating the program.  This is highly
desirable behaviour especially in a concurrent system, and was essential
in GHCi so that if the interpreted program calls System.exitWith we
don't terminate GHCi itself.

The problem is that this exception isn't propagated to the main thread
automatically if it is raised in a child thread.  Foreign-exported
functions are run in child threads.  Furthermore, it's not clear exactly
how the exception should be propagated, because there isn't always a
single main thread to send it to.

Two workarounds spring to mind:  firstly, you could wrap callbacks in a
suitable exception handler.  So instead of calling 'mkCallback e' where
mkCallback is a foreign export dynamic, you would call 'mkCallback
(Exception.catch e handler)' where handler is something like topHandler
in fptools/ghc/lib/std/PrelTopHandler.lhs, but you probably want to
discard all exceptions except ExitException.  Perhaps GHC should do this
wrapping automatically, I'm not sure.

Alternatively you could call your own version of exitWith which does a
real exit.  Again, see PrelTopHandler.lhs for the function
shutdownHaskellAndExit, which is our equivalent of hs_exit()  (when we
get around to catching up with the FFI spec, hs_exit() will probably be
a synonym for shutdownHaskellAndExit()).

Cheers,
	Simon