Win should call ::TerminateProcess to exit a renderer process

base/process/process_posix.cc

 // Copyright 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "base/process/process.h"
 
 #include <errno.h>
 #include <stdint.h>
 #include <sys/resource.h>
 #include <sys/wait.h>
@@ skipping 332 matching lines @@
       result = kill(process_, SIGKILL) == 0;
   }
 
   if (!result)
     DPLOG(ERROR) << "Unable to terminate process " << process_;
 
   return result;
 }
 #endif  // !defined(OS_NACL_NONSFI)
 
+void Process::TerminateImmediately(int exit_code) const {
+  _exit(0);

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

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]

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

+}
+
 bool Process::WaitForExit(int* exit_code) const {
   return WaitForExitWithTimeout(TimeDelta::Max(), exit_code);
 }
 
 bool Process::WaitForExitWithTimeout(TimeDelta timeout, int* exit_code) const {
   // Record the event that this thread is blocking upon (for hang diagnosis).
   base::debug::ScopedProcessWaitActivity process_activity(this);
 
   return WaitForExitWithTimeoutImpl(Handle(), exit_code, timeout);
 }
@@ skipping 13 matching lines @@
   return false;
 }
 #endif  // !defined(OS_LINUX) && !defined(OS_MACOSX)
 
 int Process::GetPriority() const {
   DCHECK(IsValid());
   return getpriority(PRIO_PROCESS, process_);
 }
 
 }  // namespace base