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. Cheers, Simon