Use ExitProcess on Windows.

Use ExitProcess on Windows.

Even after joining threads, it is still possible for the exit code to be
polluted. NaCL uses ExitProcess to avoid this problem:

https://code.google.com/p/chromium/codesearch#chromium/src/native_client/src/shared/platform/win/nacl_exit.c

This change also cleans up thread local storage for the last Thread.

BUG=
R=iposva@google.com

Committed: https://github.com/dart-lang/sdk/commit/3563dc0fb0f9a597fe8119313aa788df6a2e9efb

[zra, 2015-10-28 20:20:32]

zra@google.com changed reviewers:
+ iposva@google.com

[zra, 2015-10-28 20:21:22]

zra@google.com changed reviewers:
+ johnmccutchan@google.com

[zra, 2015-10-28 20:21:22]

+johnmccutchan for change to Thread::Shutdown()

[Cutch, 2015-10-28 20:33:15]

https://codereview.chromium.org/1410293006/diff/40001/runtime/bin/platform_wi...
File runtime/bin/platform_win.cc (right):

https://codereview.chromium.org/1410293006/diff/40001/runtime/bin/platform_wi...
runtime/bin/platform_win.cc:109: // On Windows we use ExitProcess so that
threads can't clobber the exit_code.
Can you include the NaCl issue in a comment here for reference?

https://codereview.chromium.org/1410293006/diff/40001/runtime/bin/thread_win.cc
File runtime/bin/thread_win.cc (right):

https://codereview.chromium.org/1410293006/diff/40001/runtime/bin/thread_win....
runtime/bin/thread_win.cc:115: if (handle == NULL) {
Should this be == INVALID_HANDLE_VALUE ?

https://codereview.chromium.org/1410293006/diff/40001/runtime/vm/thread.cc
File runtime/vm/thread.cc (right):

https://codereview.chromium.org/1410293006/diff/40001/runtime/vm/thread.cc#ne...
runtime/vm/thread.cc:133: OSThread::DeleteThreadLocal(thread_key_);
Can we move this TLS cleanup below the ASSERT. 

Once we know we have no more threads we don't ever care about the TLS
destructor.

[zra, 2015-10-28 21:40:04]

https://codereview.chromium.org/1410293006/diff/40001/runtime/bin/platform_wi...
File runtime/bin/platform_win.cc (right):

https://codereview.chromium.org/1410293006/diff/40001/runtime/bin/platform_wi...
runtime/bin/platform_win.cc:109: // On Windows we use ExitProcess so that
threads can't clobber the exit_code.
On 2015/10/28 20:33:15, Cutch wrote:
> Can you include the NaCl issue in a comment here for reference?

Done.

https://codereview.chromium.org/1410293006/diff/40001/runtime/bin/thread_win.cc
File runtime/bin/thread_win.cc (right):

https://codereview.chromium.org/1410293006/diff/40001/runtime/bin/thread_win....
runtime/bin/thread_win.cc:115: if (handle == NULL) {
On 2015/10/28 20:33:15, Cutch wrote:
> Should this be == INVALID_HANDLE_VALUE ?

Oddly enough, OpenThread returns NULL on an error:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms684335(v=vs.85).aspx

https://codereview.chromium.org/1410293006/diff/40001/runtime/vm/thread.cc
File runtime/vm/thread.cc (right):

https://codereview.chromium.org/1410293006/diff/40001/runtime/vm/thread.cc#ne...
runtime/vm/thread.cc:133: OSThread::DeleteThreadLocal(thread_key_);
On 2015/10/28 20:33:15, Cutch wrote:
> Can we move this TLS cleanup below the ASSERT. 

Moved.

> Once we know we have no more threads we don't ever care about the TLS
> destructor.

I was hitting a crash where ~Thread() was running called from DeleteThread()
after Shutdown(), so I'm a bit paranoid about cleaning up the TLS now.

[Ivan Posva, 2015-10-29 23:14:09]

LGTM -ip

https://codereview.chromium.org/1410293006/diff/80001/runtime/platform/globals.h
File runtime/platform/globals.h (right):

https://codereview.chromium.org/1410293006/diff/80001/runtime/platform/global...
runtime/platform/globals.h:239: #define DART_NORETURN __attribute__((noreturn))
Why?

[zra, 2015-10-30 06:09:46]

https://codereview.chromium.org/1410293006/diff/80001/runtime/platform/globals.h
File runtime/platform/globals.h (right):

https://codereview.chromium.org/1410293006/diff/80001/runtime/platform/global...
runtime/platform/globals.h:239: #define DART_NORETURN __attribute__((noreturn))
On 2015/10/29 23:14:09, Ivan Posva wrote:
> Why?

exit() is marked as not returning. If we don't mark functions wrapping exit() as
not returning as well, then the compiler won't know that execution can't
continue past them, and we'll get errors for using uninitialized variables,
etc.. This happens in main() for example.

[zra, 2015-10-30 06:35:50]

Committed patchset #6 (id:100001) manually as
3563dc0fb0f9a597fe8119313aa788df6a2e9efb.