Threading in Mono
=================
0. Terminology
--------------
"Main thread" - The initial OS-native thread that the
application started with.
"Helper thread" - A native thread created internally
by the runtime, such as the finalizer thread, or an
asynchronous delegate invocation thread. These
threads can run managed code.
"Primary CLR thread" - The native thread that called
the Main() method when executing an assembly.
"Secondary CLR thread" - A native thread created by a
program that instantiates a System.Threading.Thread object
and calls its Start() method.
1. Thread exit behaviour in the standalone mono runtime
-------------------------------------------------------
The correct behaviour of the runtime should be:
a) If Main() returns, the runtime should wait for all
foreground secondary CLR threads to finish. The
wording in the class documentation states: "Once all
foreground threads belonging to a process have
terminated, the common language runtime ends the
process by invoking Abort on any background threads
that are still alive." Testing seems to indicate that
the background thread can't cancel the Abort by
catching the ThreadAbortException and calling
ResetAbort here. Indeed, not even the finally block
seems to be executed.
b) if any of the primary CLR thread, a secondary CLR
thread or a helper thread calls
System.Environment.Exit(), the application should
terminate immediately without waiting for foreground
primary or secondary CLR threads to finish.
c) if the primary CLR thread throws an uncaught
exception, the application should terminate
immediately without waiting for secondary CLR threads
to finish. This might be implemented internally by
pretending that all the running secondary CLR threads
are background threads.
d) if a secondary CLR thread throws an uncaught
exception that thread should terminate and all other
threads should continue to execute.
e) if a helper thread throws an uncaught exception and
that thread happens to be the GC finalizer thread,
testing seems to indicate that the exception stack
trace is displayed as normal, and the exception is
then ignored (as though there is a try {} catch{}
around all finalizers that just prints the stack
trace.) Calling Abort() on the GC finalizer thread
also does not cause it to exit: it behaves as though
the ThreadAbortException is caught and ResetAbort is
called. Asynchronous delegate helper threads should
behave as secondary CLR threads, but uncaught
exceptions should be rethrown on the thread that calls
EndInvoke().
The difficulties happen with cases b) and c):
The current implementation of
System.Environment.Exit() calls exit(2) directly,
which is rather unfriendly: it prevents any runtime
cleanup, statistics gathering, etc. and is pretty
obnoxious to embedded code.
The current exception handling code calls ExitThread()
(emulated with pthread_exit() in the io-layer) if an
exception is not caught.
When called from the main thread, both POSIX
pthread_exit() and w32 ExitThread() block if there are
other threads still running (in the w32 case, if there
are other foreground threads still running; threads
can set as background.) If the main thread is also
the primary CLR thread, then the application will
block until all other threads (including helper
threads) terminate. Some helper threads will not
terminate until specifically told to by the runtime:
for example, the GC finalizer thread needs to run
until all of the primary and secondary CLR threads
have finished.
Also, if the main thread is also the primary CLR
thread, the runtime loses the opportunity to do any
cleaning up. Adding a special case to call exit(2)
instead of ExitThread() in the primary CLR thread
suffers from the same problems as
System.Environment.Exit() calling exit(2).
The simple solution is to run the primary CLR thread
in a new native thread, leaving the main thread free
for housekeeping duties. There still needs to be some
special handling for the case where the primary CLR
thread fails to catch an exception: the secondary CLR
threads then need to be terminated.
When the primary and secondary CLR threads have all
terminated, the helper threads can be killed off and
the runtime can clean itself up and exit.
2. Thread initialisation
------------------------
Threads have to undergo some initialisation before
managed code can be executed. A
System.Threading.Thread object must be created, and
the thread details need to be stored so that the
threads can be managed later. The JIT needs to record
the last managed frame stack pointer in a TLS slot,
and the current Thread object is also recorded.
New threads created by managed calls to
System.Threading.Thread methods will have all needed
initialisation performed. Threads created by the
runtime with calls to mono_thread_create() will too.
Existing threads can be passed to the runtime; these
must call mono_thread_attach() before any CLR code can
be executed on that thread.
3. Constraints on embedding the Mono runtime
--------------------------------------------
The discussion above concerning application behaviour
in the event of threads terminating, whether by
returning from the start function, throwing uncaught
exceptions or by calling System.Environment.Exit(),
only really applies to the standalone Mono runtime.
An embedding application should specify what behaviour
is required when, for example,
System.Environment.Exit() is called. The application
is also responsible for its own thread management, and
it should be prepared for any of the primary CLR
thread or secondary CLR threads to terminate at any
time. The application should also take into account
that the runtime will create helper threads as needed,
as this may cause pthread_exit() or ExitThread() to
block indefinitely, as noted above.
