Poll: System.exitWith behaviour

[Manuel M. T. Chakravarty]

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

> The current behaviour of System.exitWith doesn't really make sense in a
> concurrent environment.  The current semantics is to:
> 
>   - halt the current thread
> 
>   - run all finalizers (concurrently with any other
>     currently running threads)
> 
>   - stop the system as soon as all finalizers have
>     finished.
> 
> One high-priority problem we also have is that a program which calls
> System.exitWith from inside GHCi will shut down the whole system.
> 
> Here's my current proposal:
> 
>    - introduce a new exception constructor:
> 	 ExitException ExitCode
> 
>    - System.exitWith causes (ExitException code) to be
>      raised in the current thread.
>  
>    - If this exception propogates to the top of the thread, then
>      the main thread is also sent (ExitException code).  This
>      only happens for a standalone executable (ie. one which was
>      started by PrelMain.mainIO).
> 
>    - If this exception propogates to the top of the main thread,
>      then the system is shut down as before - all finalizers are
>      run to completion, then we exit.
> 
> For GHCi, we can obviously catch the ExitException exception and
> recover, and there is no main thread in this case.
> 
> An alternative is just to omit the third point and let the programmer
> handle propagation of the ExitException to the main thread.  This is
> somewhat consistent with our current policy of leaving these kind of
> decisions up to the programmer: we currently don't implement any kind of
> process hierarchy, and there is no requirement for child threads to
> complete before the program exits, for example.

I think, having the third point is good, because the Haskell
report requires that 

  Computation exitWith code terminates the program,
  returning code to the program's caller.

Cheers,
Manuel