When a thread is terminated violently (such as by using TerminateThread)
that is not the current thread, the server sends a signal to the thread to
terminate it, but it immediately wakes up anything waiting on it. The caller
can expect WaitForSingleObject (or similar) to return when the thread is
really gone and doesn't execute anything anymore, and this is exactly what
happens on Windows.

If that thread was altering global state, and the thread that was waiting
on it will read (or alter) the global state *after* waiting for it and
expecting it to not change (because it assumes the thread is terminated by
that point, as on Windows), the result will be a race condition, since there's
no guarantee currently that the terminated thread really stopped executing.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>