nspr_s_position_on_abrupt_thread_termination.rst

NSPR's position on abrupt thread termination

============================================

This memo describes my position on a facility that is currently under

discussion for inclusion in the NetScape Portable Runtime (NSPR); the

ability of a thread to abruptly exit. I resist including this function

in NSPR because it results in bad programming practice and unsupportable

programs.

   *Threads are not processes.*

Abrupt termination has been available in the UNIX/C environment for some

time (``exit()``), and I assume that the basic semantics defined there

are applicable here. In that environment, ``exit()`` may be called and

any time, and results in the calling thread's immediate termination. In

the situation where it was defined (UNIX), which has only a single

thread of execution, that is equivalent to terminating the process. The

process abstraction is then responsible for closing all open files and

reclaiming all storage that may have been allocated during the process'

lifetime.

This practice does not extend to threads. Threads run within the

confines of a process (or similar abstractions in other environments).

Threads are lightweight because they do not maintain the full protection

domain provided by a process. So in a threaded environment, what is the

parallel to UNIX' ``exit()``?

NSPR has defined a function, callable by any thread within a process at

any time, called ``PR_ProcessExit()``. This is identical to UNIX

``exit()`` and was so named in an effort to make the obvious even more

so. When called, the process exits, closing files and reclaiming the

process' storage.

Certain people have been disappointed when NSPR did not provide a

functional equivalent to exit just a particular thread. Apparently they

have failed to consider the ramifications. If a thread was to abruptly

terminate, there is no recording of what resources it owns and should

therefore be reclaimed. Those resources are in fact, owned by the

process and shared by all the threads within the process.

In the general course of events when programming with threads, it is

very advantageous for a thread to have resources that it and only it

knows about. In the natural course of events, these resources will be

allocated by a thread, used for some period of time, and then freed as

the stack unwinds. In these cases, the presence of the data is recorded

only on the stack, known only to the single thread (normally referred to

as *encapsulated*).

The problem with abrupt termination is that it can happen at any time,

to a thread that is coded correctly to handle both normal and

exceptional situations, but will be unable to do so since it will be

denied the opportunity to complete execution. It can happen because it

called out of its own scope into some lazily implemented library.

NSPR's answer to this is that there is no abrupt thread termination. All

threads must unwind and return from their root function. If they cannot,

because of some state corruption, then they must assume that the

corruption, like the state, is shared, and their only resource is for

the process to terminate.

To make this solution work requires that a function that encounters an

error be designed such that it first repairs its immediate state, and

then reports that error to its caller. If the caller cannot deal with

the failure, it must do the same. This process continues until the

thread either recovers from the malady or returns from the root

function. This is not all that difficult (though having done it a number

of times to already existing code, I will admit it isn't much fun

either).

The implementation of either strategy within the NSPR runtime is not

difficult. That is not what this memo is about. This is about providing

an API that coaxes people to do the right thing in as many ways as

possible. The existence of ``exit()`` in the UNIX/C environment is a

perfect example of how programmers will employ the most expediant

solution available. The definition of the language C is such that

returning from ``main()`` is a perfectly fine thing to do. But what

percentage of C programs actually bother? In UNIX, with its complex

definition of a protection domain, it happens to work (one might even

say it's more efficient) to exit from anywhere. But threads are not

processes. If threads have to maintain the same type of resource

knowledge as a process, they loose all of their benefit.

Threads are an implementation strategy to provide the illusion of

concurrency within a process. They are alternatives to large state

machines with mostly non-blocking library functions. When the latter is

used to provide concurrency, calling ``exit()`` will terminate the

entire process. Why would anyone expect a thread to behave differently?

Threads are not processes.