"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