Sometimes we intentionally kill the GPU process (the workaround is enabled on Windows and Android) when there was a lost context through robustness i.e. GPU reset.

The distinction between this and another intentional shutdown is not clear to the browser. (On Android it is, or it doesn't matter, since we only have the notion of the app having been or having not been in the foreground, and the former is a crash for all we care and the latter is not.)

I tried to bypass 3d api blocking for normal shutdown as seen by the browser in https://codereview.chromium.org/1749263003/.
However in https://codereview.chromium.org/1747283003/ I noticed this is flaky depending on the platform, since although we also have another context-specific api blocking codepath (see GpuProcessHost::DidLoseContext), it's not clear which context will see the gpu reset first and initiate the shutdown (and with 'exit_on_context_lost' we only see DidLostContext once).

I'm wondering if the #ifdef Android here can be eliminated by propagating that the process was shutdown for 'exit_on_context_lost' differently:

GpuProcessHost::~GPProcessHost() {
...
#if defined(OS_ANDROID)
  497         block_offscreen_contexts = false;	  500         block_offscreen_contexts = false;
#endif

Sending an IPC seems flaky at shutdown. Maybe we can plumb an 'exit status' and translate it to an internal TERMINATION_STATUS. Since we don't call exit() but shutdown the message loop, I assume it'd have to be the code returned from 'int GpuMain()' and plumbed through ChildProcessLauncher and waitpid() etc.