Win should call ::TerminateProcess to exit a renderer process

Win should call ::TerminateProcess to exit a renderer process

Win should not call _exit(0) because the behavior is odd.
(See more discussion in https://codereview.chromium.org/2309153002/.)
Instead, Win should use ::TerminateProcess.

BUG=639244
Review-Url: https://codereview.chromium.org/2629623003
Cr-Commit-Position: refs/heads/master@{#448916}
Committed: https://chromium.googlesource.com/chromium/src/+/940efb95e8eb38337c4df327792b71dcc2de2d84

[haraken, 2017-01-13 02:49:02]

The CQ bit was checked by haraken@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-13 02:49:28]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-13 03:26:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-13 03:26:44]

Dry run: Try jobs failed on following builders:
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[haraken, 2017-01-13 03:43:48]

The CQ bit was checked by haraken@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-13 03:44:37]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-13 05:03:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-13 05:03:07]

Dry run: This issue passed the CQ dry run.

[haraken, 2017-01-13 05:04:01]

haraken@chromium.org changed reviewers:
+ primiano@chromium.org, thakis@chromium.org

[haraken, 2017-01-13 05:04:01]

PTAL

[Primiano Tucci (use gerrit), 2017-01-13 17:08:17]

See comments below.
Also since the harness is already there (see process_unittest.cc) I'd add a test
for this feature. It is quite easy to regress the exit code by refactoring this
code, and if we do this one year from now, it might end up silently screwing up
our OOM stats.

https://codereview.chromium.org/2629623003/diff/20001/base/process/process_po...
File base/process/process_posix.cc (right):

https://codereview.chromium.org/2629623003/diff/20001/base/process/process_po...
base/process/process_posix.cc:354: _exit(0);
two things here:
1) s/0/exit_code/ :)
2) note that in the current API Process is an object that can be a remote
process, not the current one.
The way this is implemented  is a bit contra-intuitive beause you can do

Process another = Process.Open(...)
another.TerminateImmediately()

the expectation in this case is that it would terminate immediately the |other|
process. Instead this will terminate the current one, leaving everybody
amazingly surprised.

I think the possible ways to deal with this is:

1) Make this a static method and call it TerminateCurrentProcessImmediately
2) CHECK(is_current()) << "Immediate termination of another process is not a
supported use case")
3) Just kill(process_, SIGKILL) (in which case I'd refactor and extract the
common code from ::Terminate instead of duplicating)

3 has a small drawback, when you SIGKILL the process will exit immediately, but
with an exit code of != 0 (specifically 137 if I did the math correctly). Not
sure if this (the fact that a child dies with != 0) will confuse the browser
process, letting it kill that the process was killed by an external event
(concretely if we have any sort of code that tries to account child processes
OOM, this might be confused for a kill due to OOM)

Very likely terminating immediately another process is not a use case that we
care about, so I would go either for 1 or for 2.

[Nico, 2017-01-13 19:24:59]

https://codereview.chromium.org/2629623003/diff/20001/base/process/process_po...
File base/process/process_posix.cc (right):

https://codereview.chromium.org/2629623003/diff/20001/base/process/process_po...
base/process/process_posix.cc:354: _exit(0);
On 2017/01/13 17:08:17, Primiano Tucci wrote:
> two things here:
> 1) s/0/exit_code/ :)
> 2) note that in the current API Process is an object that can be a remote
> process, not the current one.
> The way this is implemented  is a bit contra-intuitive beause you can do
> 
> Process another = Process.Open(...)
> another.TerminateImmediately()
> 
> the expectation in this case is that it would terminate immediately the
|other|
> process. Instead this will terminate the current one, leaving everybody
> amazingly surprised.
> 
> I think the possible ways to deal with this is:
> 
> 1) Make this a static method and call it TerminateCurrentProcessImmediately
> 2) CHECK(is_current()) << "Immediate termination of another process is not a
> supported use case")
> 3) Just kill(process_, SIGKILL) (in which case I'd refactor and extract the
> common code from ::Terminate instead of duplicating)
> 
> 3 has a small drawback, when you SIGKILL the process will exit immediately,
but
> with an exit code of != 0 (specifically 137 if I did the math correctly). Not
> sure if this (the fact that a child dies with != 0) will confuse the browser
> process, letting it kill that the process was killed by an external event
> (concretely if we have any sort of code that tries to account child processes
> OOM, this might be confused for a kill due to OOM)
> 
> Very likely terminating immediately another process is not a use case that we
> care about, so I would go either for 1 or for 2. 

Agreed, 1 or 2 seem more appropriate. 1 seems a tiny bit simpler to me, but up
to you.

[haraken, 2017-01-16 02:02:37]

The CQ bit was checked by haraken@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-16 02:02:53]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-16 02:38:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-16 02:38:55]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[haraken, 2017-01-16 04:15:02]

On 2017/01/13 17:08:17, Primiano Tucci wrote:
> See comments below.
> Also since the harness is already there (see process_unittest.cc) I'd add a
test
> for this feature. It is quite easy to regress the exit code by refactoring
this
> code, and if we do this one year from now, it might end up silently screwing
up
> our OOM stats.

How can we test TerminateCurrentProcessImmediately? Since it exits the *current*
process immediately, we cannot test the behavior by
process.TerminateCurrentProcessImmediately() or something. See the patch set 3
-- it doesn't work.

> 
>
https://codereview.chromium.org/2629623003/diff/20001/base/process/process_po...
> File base/process/process_posix.cc (right):
> 
>
https://codereview.chromium.org/2629623003/diff/20001/base/process/process_po...
> base/process/process_posix.cc:354: _exit(0);
> two things here:
> 1) s/0/exit_code/ :)
> 2) note that in the current API Process is an object that can be a remote
> process, not the current one.
> The way this is implemented  is a bit contra-intuitive beause you can do
> 
> Process another = Process.Open(...)
> another.TerminateImmediately()
> 
> the expectation in this case is that it would terminate immediately the
|other|
> process. Instead this will terminate the current one, leaving everybody
> amazingly surprised.
> 
> I think the possible ways to deal with this is:
> 
> 1) Make this a static method and call it TerminateCurrentProcessImmediately
> 2) CHECK(is_current()) << "Immediate termination of another process is not a
> supported use case")
> 3) Just kill(process_, SIGKILL) (in which case I'd refactor and extract the
> common code from ::Terminate instead of duplicating)
> 
> 3 has a small drawback, when you SIGKILL the process will exit immediately,
but
> with an exit code of != 0 (specifically 137 if I did the math correctly). Not
> sure if this (the fact that a child dies with != 0) will confuse the browser
> process, letting it kill that the process was killed by an external event
> (concretely if we have any sort of code that tries to account child processes
> OOM, this might be confused for a kill due to OOM)
> 
> Very likely terminating immediately another process is not a use case that we
> care about, so I would go either for 1 or for 2.

Adopted 1).

[Primiano Tucci (use gerrit), 2017-01-16 14:37:34]

https://codereview.chromium.org/2629623003/diff/40001/base/process/process.h
File base/process/process.h (right):

https://codereview.chromium.org/2629623003/diff/40001/base/process/process.h#...
base/process/process.h:106: void TerminateCurrentProcessImmediately(int
exit_code) const;
+static (and move up with the other statics) as this does not make sense as a
member function

https://codereview.chromium.org/2629623003/diff/40001/base/process/process_un...
File base/process/process_unittest.cc (right):

https://codereview.chromium.org/2629623003/diff/40001/base/process/process_un...
base/process/process_unittest.cc:163:
process.TerminateCurrentProcessImmediately(kExpectedExitCode);
well this is the problem. You don't want to terminate the test_f process, but
the child one.
concretely I think you need to add a :
MULTIPROCESS_TEST_MAIN(TerminateImmediatelyChildProcess) {
  Process::TerminateCurrentProcessImmediately(kExpectedExitCode);
  return 0;
}

and here in this funciton you SpawnChild("TerminateImmediatelyChildProcess") and
check that it did exit with kExpectedExitCode

https://codereview.chromium.org/2629623003/diff/40001/base/process/process_un...
base/process/process_unittest.cc:170: // The POSIX implementation actually
ignores the exit_code.
Where did this happen? I tried both on OSX and Linux and it seems to be
respected.

[haraken, 2017-01-17 00:01:22]

The CQ bit was checked by haraken@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-17 00:01:39]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-17 00:14:24]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-17 00:14:25]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[haraken, 2017-01-17 00:33:22]

The CQ bit was checked by haraken@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-17 00:33:42]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-17 01:01:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-17 01:01:42]

Dry run: Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[haraken, 2017-01-17 01:04:58]

The CQ bit was checked by haraken@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-17 01:05:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-17 02:01:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-17 02:01:54]

Dry run: This issue passed the CQ dry run.

[haraken, 2017-01-17 02:39:42]

PTAL

[Primiano Tucci (use gerrit), 2017-01-17 07:55:16]

https://codereview.chromium.org/2629623003/diff/100001/base/process/process_u...
File base/process/process_unittest.cc (right):

https://codereview.chromium.org/2629623003/diff/100001/base/process/process_u...
base/process/process_unittest.cc:151:
MULTIPROCESS_TEST_MAIN(TerminateCurrentProcessImmediately) {
Well this is good but no sufficient. 
You still need a TEST_F thay uses this, like the one  you had in your previous
patch set

https://codereview.chromium.org/2629623003/diff/100001/content/renderer/rende...
File content/renderer/render_thread_impl.cc (right):

https://codereview.chromium.org/2629623003/diff/100001/content/renderer/rende...
content/renderer/render_thread_impl.cc:951:
base::Process::Current().TerminateCurrentProcessImmediately(0);
No need for current() here

[haraken, 2017-01-17 09:13:07]

The CQ bit was checked by haraken@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-17 09:13:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-17 09:25:48]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-17 09:25:48]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[haraken, 2017-01-17 09:40:00]

The CQ bit was checked by haraken@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-17 09:40:10]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[haraken, 2017-01-17 09:40:27]

PTAL

https://codereview.chromium.org/2629623003/diff/140001/base/process/process_u...
File base/process/process_unittest.cc (right):

https://codereview.chromium.org/2629623003/diff/140001/base/process/process_u...
base/process/process_unittest.cc:174: #if !defined(OS_POSIX)

It looks like this guard is needed. In Linux, exit_code is 0 here.

[commit-bot: I haz the power, 2017-01-17 10:10:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-17 10:10:16]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[haraken, 2017-01-17 10:58:10]

The CQ bit was checked by haraken@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-17 10:58:20]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-17 11:59:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-17 11:59:01]

Dry run: This issue passed the CQ dry run.

[Primiano Tucci (use gerrit), 2017-01-17 12:08:21]

https://codereview.chromium.org/2629623003/diff/140001/base/process/process_u...
File base/process/process_unittest.cc (right):

https://codereview.chromium.org/2629623003/diff/140001/base/process/process_u...
base/process/process_unittest.cc:174: #if !defined(OS_POSIX)
On 2017/01/17 09:40:27, haraken wrote:
> 
> It looks like this guard is needed. In Linux, exit_code is 0 here.
> 

I insist, on linux the exit code works really fine. The problem is that here you
are creating a race because you first wait for the process to exit and then get
its termination status. you cannot detect the termination status twice.
If you did build this in debug with logging, you would have seen this:
[16030:16030:0117/113305.527613:1125986610551:ERROR:kill_posix.cc(34)]
waitpid(16031): No child processes

so what happens is that you are getting 0 because you make the process go away
with the first call to WaitForExitWithTimeout and then you poll a non existing
process with GetTerminationStatus.

I think you here want to super-simplify this:

-----
MULTIPROCESS_TEST_MAIN(TerminateCurrentProcessImmediatelyWithCode0) {
  Process::TerminateCurrentProcessImmediately(0);
  NOTREACHED();
  return 42;
}

TEST_F(ProcessTest, TerminateCurrentProcessImmediatelyWithZeroExitCode) {
  Process process(SpawnChild("TerminateCurrentProcessImmediatelyWithCode0"));
  ASSERT_TRUE(process.IsValid());
  int exit_code = 42;
  ASSERT_TRUE(process.WaitForExitWithTimeout(TestTimeouts::action_max_timeout(),
                                             &exit_code));
  EXPECT_EQ(0, exit_code);
}

MULTIPROCESS_TEST_MAIN(TerminateCurrentProcessImmediatelyWithCode250) {
  Process::TerminateCurrentProcessImmediately(250);
  NOTREACHED();
  return 42;
}

TEST_F(ProcessTest, TerminateCurrentProcessImmediatelyWithNonZeroExitCode) {
  Process process(SpawnChild("TerminateCurrentProcessImmediatelyWithCode250"));
  ASSERT_TRUE(process.IsValid());
  int exit_code = 42;
  ASSERT_TRUE(process.WaitForExitWithTimeout(TestTimeouts::action_max_timeout(),
                                             &exit_code));
  EXPECT_EQ(250, exit_code);
}
-----

I tried this in my linux workstation and it works

[haraken, 2017-01-19 11:16:44]

On 2017/01/17 12:08:21, Primiano Tucci wrote:
>
https://codereview.chromium.org/2629623003/diff/140001/base/process/process_u...
> File base/process/process_unittest.cc (right):
> 
>
https://codereview.chromium.org/2629623003/diff/140001/base/process/process_u...
> base/process/process_unittest.cc:174: #if !defined(OS_POSIX)
> On 2017/01/17 09:40:27, haraken wrote:
> > 
> > It looks like this guard is needed. In Linux, exit_code is 0 here.
> > 
> 
> I insist, on linux the exit code works really fine. The problem is that here
you
> are creating a race because you first wait for the process to exit and then
get
> its termination status. you cannot detect the termination status twice.
> If you did build this in debug with logging, you would have seen this:
> [16030:16030:0117/113305.527613:1125986610551:ERROR:kill_posix.cc(34)]
> waitpid(16031): No child processes
> 
> so what happens is that you are getting 0 because you make the process go away
> with the first call to WaitForExitWithTimeout and then you poll a non existing
> process with GetTerminationStatus.
> 
> I think you here want to super-simplify this:
> 
> -----
> MULTIPROCESS_TEST_MAIN(TerminateCurrentProcessImmediatelyWithCode0) {
>   Process::TerminateCurrentProcessImmediately(0);
>   NOTREACHED();
>   return 42;
> }
> 
> TEST_F(ProcessTest, TerminateCurrentProcessImmediatelyWithZeroExitCode) {
>   Process process(SpawnChild("TerminateCurrentProcessImmediatelyWithCode0"));
>   ASSERT_TRUE(process.IsValid());
>   int exit_code = 42;
>  
ASSERT_TRUE(process.WaitForExitWithTimeout(TestTimeouts::action_max_timeout(),
>                                              &exit_code));
>   EXPECT_EQ(0, exit_code);
> }
> 
> MULTIPROCESS_TEST_MAIN(TerminateCurrentProcessImmediatelyWithCode250) {
>   Process::TerminateCurrentProcessImmediately(250);
>   NOTREACHED();
>   return 42;
> }
> 
> TEST_F(ProcessTest, TerminateCurrentProcessImmediatelyWithNonZeroExitCode) {
>   Process
process(SpawnChild("TerminateCurrentProcessImmediatelyWithCode250"));
>   ASSERT_TRUE(process.IsValid());
>   int exit_code = 42;
>  
ASSERT_TRUE(process.WaitForExitWithTimeout(TestTimeouts::action_max_timeout(),
>                                              &exit_code));
>   EXPECT_EQ(250, exit_code);
> }
> -----
> 
> I tried this in my linux workstation and it works

Thanks, done.

[haraken, 2017-01-19 11:16:50]

The CQ bit was checked by haraken@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-19 11:17:10]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Primiano Tucci (use gerrit), 2017-01-19 12:48:04]

thanks, LGTM

[commit-bot: I haz the power, 2017-01-19 13:14:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-19 13:14:04]

Dry run: This issue passed the CQ dry run.

[haraken, 2017-01-19 13:58:14]

The CQ bit was checked by haraken@chromium.org

[commit-bot: I haz the power, 2017-01-19 13:58:28]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-19 14:05:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-19 14:05:18]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[haraken, 2017-01-19 14:07:41]

haraken@chromium.org changed reviewers:
+ kinuko@chromium.org

[haraken, 2017-01-19 14:07:41]

thakis@: PTAL at base/ ?
kinuko@: rs at renderer/ ?

[kinuko, 2017-01-19 15:20:45]

On 2017/01/19 14:07:41, haraken wrote:
> thakis@: PTAL at base/ ?
> kinuko@: rs at renderer/ ?

renderer change lgtm

[haraken, 2017-02-07 08:41:51]

thakis@: friendly ping?

[Nico, 2017-02-07 15:19:34]

base/ lgtm

https://codereview.chromium.org/2629623003/diff/180001/base/process/process_u...
File base/process/process_unittest.cc (right):

https://codereview.chromium.org/2629623003/diff/180001/base/process/process_u...
base/process/process_unittest.cc:152:
Process::TerminateCurrentProcessImmediately(0);
maybe this test should register an atexit handler and check that it's not
getting called?

[Primiano Tucci (use gerrit), 2017-02-07 15:48:11]

https://codereview.chromium.org/2629623003/diff/180001/base/process/process_u...
File base/process/process_unittest.cc (right):

https://codereview.chromium.org/2629623003/diff/180001/base/process/process_u...
base/process/process_unittest.cc:152:
Process::TerminateCurrentProcessImmediately(0);
On 2017/02/07 15:19:34, Nico wrote:
> maybe this test should register an atexit handler and check that it's not
> getting called?

oh very good point. I guess you could both:
- register an atexithandler with does a CHECK(false):
- initialize a ThreadLocalStorage entry with a destructor that does the same
to check that neither explicit handlers nor libc/crt handled ones are triggered.

[haraken, 2017-02-08 04:21:42]

On 2017/02/07 15:48:11, Primiano Tucci wrote:
>
https://codereview.chromium.org/2629623003/diff/180001/base/process/process_u...
> File base/process/process_unittest.cc (right):
> 
>
https://codereview.chromium.org/2629623003/diff/180001/base/process/process_u...
> base/process/process_unittest.cc:152:
> Process::TerminateCurrentProcessImmediately(0);
> On 2017/02/07 15:19:34, Nico wrote:
> > maybe this test should register an atexit handler and check that it's not
> > getting called?
> 
> oh very good point. I guess you could both:
> - register an atexithandler with does a CHECK(false):
> - initialize a ThreadLocalStorage entry with a destructor that does the same
> to check that neither explicit handlers nor libc/crt handled ones are
triggered.

Done.

[haraken, 2017-02-08 04:21:48]

The CQ bit was checked by haraken@chromium.org

[haraken, 2017-02-08 04:21:49]

The patchset sent to the CQ was uploaded after l-g-t-m from
primiano@chromium.org, kinuko@chromium.org, thakis@chromium.org
Link to the patchset: https://codereview.chromium.org/2629623003/#ps200001
(title: "temp")

[commit-bot: I haz the power, 2017-02-08 04:22:11]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-08 05:58:19]

CQ is committing da patch.

Bot data: {"patchset_id": 200001, "attempt_start_ts": 1486527708933170,
"parent_rev": "ae9143a9d87c734f5b31f72f296917cc8bc24588", "commit_rev":
"940efb95e8eb38337c4df327792b71dcc2de2d84"}

[commit-bot: I haz the power, 2017-02-08 05:58:49]

Description was changed from

==========
Win should call ::TerminateProcess to exit a renderer process

Win should not call _exit(0) because the behavior is odd.
(See more discussion in https://codereview.chromium.org/2309153002/.)
Instead, Win should use ::TerminateProcess.

BUG=639244
==========

to

==========
Win should call ::TerminateProcess to exit a renderer process

Win should not call _exit(0) because the behavior is odd.
(See more discussion in https://codereview.chromium.org/2309153002/.)
Instead, Win should use ::TerminateProcess.

BUG=639244

Review-Url: https://codereview.chromium.org/2629623003
Cr-Commit-Position: refs/heads/master@{#448916}
Committed:
https://chromium.googlesource.com/chromium/src/+/940efb95e8eb38337c4df327792b...
==========

[commit-bot: I haz the power, 2017-02-08 05:58:51]

Committed patchset #11 (id:200001) as
https://chromium.googlesource.com/chromium/src/+/940efb95e8eb38337c4df327792b...