Poll: System.exitWith behaviour

Simon Marlow simonmar@microsoft.com
Tue, 22 May 2001 15:43:45 +0100

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.