Add minimal support for process_utils on iOS

Add minimal support for process_utils on iOS

Much of process_utils isn't meaningful on iOS, but this provides enough to support unit tests and minimal metrics.

BUG=None
TEST=None


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=146123

[Mark Mentovai, 2012-07-11 12:36:50]

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_ios.mm
File base/process_util_ios.mm (right):

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_ios....
base/process_util_ios.mm:8: #include <iostream>
C++ system headers belong in a separate section than C system headers, and they
should be after C system headers.

But you can maybe just remove this (see the next comment).

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_ios....
base/process_util_ios.mm:24: std::cerr << "\t" << [stack_symbol UTF8String] <<
"\n";
When do we ever use C++ streams and cerr as opposed to fprintf and stderr?
Never. The style guide forbids streams except for logging.

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_ios....
base/process_util_ios.mm:38: }  // anonymous namespace
Normally, anonymous namespaces just close with // namespace.

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_ios....
base/process_util_ios.mm:77: ProcessMetrics::PortProvider* port_provider) {}
The port provider interface is nonsense on iOS, which normally I’d ignore,
except we also have the non-Mac form of ProcessMetrics that doesn’t have a
PortProvider argument to the constructor. Why don’t we use that
PortProvider-free form for iOS too?

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_unit...
File base/process_util_unittest_ios.cc (right):

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_unit...
base/process_util_unittest_ios.cc:11:
base::ProcessMetrics::CreateProcessMetrics(NULL, NULL));
You should at least pretend to do the right thing and use
GetCurrentProcessHandle (which should just return GetCurrentProcId).

[stuartmorgan, 2012-07-11 13:56:57]

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_ios.mm
File base/process_util_ios.mm (right):

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_ios....
base/process_util_ios.mm:8: #include <iostream>
On 2012/07/11 12:36:51, Mark Mentovai wrote:
> But you can maybe just remove this (see the next comment).

Done.

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_ios....
base/process_util_ios.mm:24: std::cerr << "\t" << [stack_symbol UTF8String] <<
"\n";
On 2012/07/11 12:36:51, Mark Mentovai wrote:
> When do we ever use C++ streams and cerr as opposed to fprintf and stderr?
> Never. The style guide forbids streams except for logging.

Done.

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_ios....
base/process_util_ios.mm:38: }  // anonymous namespace
On 2012/07/11 12:36:51, Mark Mentovai wrote:
> Normally, anonymous namespaces just close with // namespace.

Done.

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_ios....
base/process_util_ios.mm:77: ProcessMetrics::PortProvider* port_provider) {}
On 2012/07/11 12:36:51, Mark Mentovai wrote:
> The port provider interface is nonsense on iOS, which normally I’d ignore,
> except we also have the non-Mac form of ProcessMetrics that doesn’t have a
> PortProvider argument to the constructor. Why don’t we use that
> PortProvider-free form for iOS too?

Done. (I suspect it was the other way to avoid changing the ifdef's on all the
call sites, but now that we're upstreaming it there's no reason to care about
that any more)

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_unit...
File base/process_util_unittest_ios.cc (right):

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_unit...
base/process_util_unittest_ios.cc:11:
base::ProcessMetrics::CreateProcessMetrics(NULL, NULL));
On 2012/07/11 12:36:51, Mark Mentovai wrote:
> You should at least pretend to do the right thing and use
> GetCurrentProcessHandle (which should just return GetCurrentProcId).

Done.

[Mark Mentovai, 2012-07-11 14:04:21]

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_ios.mm
File base/process_util_ios.mm (right):

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_ios....
base/process_util_ios.mm:77: ProcessMetrics::PortProvider* port_provider) {}
stuartmorgan wrote:
> Done. (I suspect it was the other way to avoid changing the ifdef's on all the
> call sites, but now that we're upstreaming it there's no reason to care about
> that any more)

I thought that might be it and even hypothesized about it a bit in my comment
and gave you some wishy-washy latitude to weigh call sites against cleanliness.
In the end, I tore all of that stuff out when I realized that the ProcessMetrics
constructor is private and is only called by CreateProcessMetrics.

https://chromiumcodereview.appspot.com/10698149/diff/4001/base/base.gypi
File base/base.gypi (right):

https://chromiumcodereview.appspot.com/10698149/diff/4001/base/base.gypi#newc...
base/base.gypi:578: ['include', '^process_util_ios.mm'],
(Double-)backslash that dot and gimme a dollar sign at the end.

https://chromiumcodereview.appspot.com/10698149/diff/4001/base/mac/foundation...
File base/mac/foundation_util.mm (right):

https://chromiumcodereview.appspot.com/10698149/diff/4001/base/mac/foundation...
base/mac/foundation_util.mm:34: #if defined(OS_IOS)
Uh-oh, your changes are colliding…

[stuartmorgan, 2012-07-11 14:18:03]

Sorry about the patch bleed; I'm playing some games with my tree to chain my
patches for test builds to see what to do next, but unchain to test that the
order they land it doesn't matter. Fixed now.

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_ios.mm
File base/process_util_ios.mm (right):

https://chromiumcodereview.appspot.com/10698149/diff/1/base/process_util_ios....
base/process_util_ios.mm:77: ProcessMetrics::PortProvider* port_provider) {}
On 2012/07/11 14:04:21, Mark Mentovai wrote:
> stuartmorgan wrote:
> > Done. (I suspect it was the other way to avoid changing the ifdef's on all
the
> > call sites, but now that we're upstreaming it there's no reason to care
about
> > that any more)
> 
> I thought that might be it and even hypothesized about it a bit in my comment
> and gave you some wishy-washy latitude to weigh call sites against
cleanliness.
> In the end, I tore all of that stuff out when I realized that the
ProcessMetrics
> constructor is private and is only called by CreateProcessMetrics.

Sure, but the same logic applies to the CreateProcessMetrics function fronting
it, which also has both forms. So there will be call sites that need changing,
but I'm fine changing them. It won't add any new ifdefs, just make the existing
ones have a longer condition.

https://chromiumcodereview.appspot.com/10698149/diff/4001/base/base.gypi
File base/base.gypi (right):

https://chromiumcodereview.appspot.com/10698149/diff/4001/base/base.gypi#newc...
base/base.gypi:578: ['include', '^process_util_ios.mm'],
On 2012/07/11 14:04:22, Mark Mentovai wrote:
> (Double-)backslash that dot and gimme a dollar sign at the end.

Done.

[Mark Mentovai, 2012-07-11 14:25:52]

LGTM

[commit-bot: I haz the power, 2012-07-11 14:31:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/stuartmorgan@chromium.org/10698149/5006

[commit-bot: I haz the power, 2012-07-11 15:35:04]

Change committed as 146123