[HOpenGL] news on FFI?

[Manuel M. T. Chakravarty]

"Simon Marlow" <simonmar@microsoft.com> wrote,

> > > I would like to know if that will help to solve that 
> > "uncaught exception
> > > problem" when leaving HOpenGL programs.
> > 
> > A strictly conforming implementation shouldn't have that problem, see:
> > 
> >   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.

That sounds like a good solution to me. 

> 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()).

This one has the disadvantage that it would kill GHCi when
this happens in interactive mode - the reason for making
exitWith based on exceptions in the first place.  (BTW, the
hs_exit() bit I didn't do in my FFI commit.  Mainly because
this extra argument to the initialisation function seems to
require some more thought.)

Cheers,
Manuel