Enable --single-process for Mac and Linux.
Additionally, wire in a bit of setup for the --single-process case,
because it cannot be done by the renderer thread because that thread
is not the main thread.
Fair warning: --single-process often seems to be broken by various
unrelated changes, which may-or-may-not make assumptions about the
process architecture. I will try to stay on top of these.
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=10559

With this change, I still get a crash in WebViewImpl::DownloadImage(), unless I
patch in an early return of true. Which isn't right. But I think this makes
things comparable to what you're seeing.
I think you were also looking at the render_thread.cc change, is there something
deeper at work that I'm missing? Yes, it crashes, but it's easier to not crash
if you don't have a RenderView :-).

OK, John, after browsing around about how things are used, I think I understand
your points about RendererMainPlatformDelegate better. I had a
misunderstanding. The new CL should be better.
http://codereview.chromium.org/21330/diff/1005/11
File chrome/app/chrome_dll_main.cc (right):
http://codereview.chromium.org/21330/diff/1005/11#newcode319
Line 319: }
An alternative to this would be to push the if() into the process_type.empty()
case below and duplicate the call to BrowerMain(), once in the if(), once in the
else. I'm a little mixed on whether that's the appropriate thing to do.

jeremy

http://codereview.chromium.org/21330/diff/1005/11 File chrome/app/chrome_dll_main.cc (right): http://codereview.chromium.org/21330/diff/1005/11#newcode319 Line 319: } Does this work on Windows? My only ...

http://codereview.chromium.org/21330/diff/1005/11
File chrome/app/chrome_dll_main.cc (right):
http://codereview.chromium.org/21330/diff/1005/11#newcode319
Line 319: }
Does this work on Windows?
My only concern here is that this might trip up people editing code in
RenderMainPlatformDelegate, since your using a calling pattern that's different
from the one in RendererMain.
I'm fine with these changes as long as you add documentation to
renderer_main_platform_delegate.h explaining that
InitSandboxTests/EnableSandbox/RunSandboxTests won't be called in single process
mode.
And that the only guarantees for PlatformUn/Initialize are that they'll be
called before/after the sandbox is turned on (if it's turned on) and
before/after process main otherwise.

Scott Hess - ex-Googler

Carlos says no for Windows, which means it will need refactoring. I think the distinction ...

Carlos says no for Windows, which means it will need refactoring. I think the
distinction wanted is:
- things which are necessary to make a process on the platform viable.
- things which are necessary to let a process host a renderer.
On Windows PlatformInitialize() is all the first, on Mac it's all the second, on
Linux it's empty.

Scott Hess - ex-Googler

Look again? This is really ugly. I'm starting to wish for a simple #ifdef in ...

Look again?
This is really ugly. I'm starting to wish for a simple #ifdef in
chrome_dll_main.cc.

jeremy

http://codereview.chromium.org/21330/diff/1007/20 File chrome/renderer/renderer_main_platform_delegate.h (right): http://codereview.chromium.org/21330/diff/1007/20#newcode30 Line 30: // the sandbox. Do not call if not ...

I should get this out of my client so I can move on. John and Jeremy are OOO.
The story is, this is where I started with things, John thought I should try to
use RendererMainPlatformDelegate instead so that we wouldn't miss out on other
essential start-up stuff, worked that around for awhile, then finally found that
DEPS forbids that dependency (and it didn't show up anywhere but Linux, and even
there it didn't fail earlier). So, now I'm back to square one, and using TODO()
to fill in for refactoring.
With this, you can use it as a browser pretty successfully.