Poll: System.exitWith behaviour
Manuel M. T. Chakravarty
Wed, 23 May 2001 16:50:42 +1000
"Simon Marlow" <firstname.lastname@example.org> 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
> 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.