Implement CurrentProcessInfo::CreationTime() for Linux.

Implement CurrentProcessInfo::CreationTime() for Linux.

With this CL, we'll now have cold start metrics on Android.

R=darin
BUG=None

[gavinp, 2013-08-07 16:42:22]

Now we can do Cold Start measurements on ALL the platforms.

[gavinp, 2013-08-07 16:42:44]

On 2013/08/07 16:42:22, gavinp wrote:
> Now we can do Cold Start measurements on ALL the platforms.

Also, note that this method would be second resolution only without also landing
https://codereview.chromium.org/22582009/

[darin (slow to review), 2013-08-07 19:21:47]

LGTM

[gavinp, 2013-08-07 20:48:09]

Darin,

Please take  another look. This code was failing in some downstream CLs due to
the IO restriction. I had to violate the presubmit hooks to even upload a CL
containing ScopedAllowIO, however, I think PostTask would be very much overkill
here since this "IO" is with a "file" that is created in memory on access.

What do you think?

[darin (slow to review), 2013-08-07 22:30:34]

https://chromiumcodereview.appspot.com/22594007/diff/24001/base/process/proce...
File base/process/process_info_linux.cc (right):

https://chromiumcodereview.appspot.com/22594007/diff/24001/base/process/proce...
base/process/process_info_linux.cc:28: if (!file_util::GetFileInfo(pid_path,
&file_info))
maybe the code that complains about GetFileInfo being called on a UI thread
should avoid complaining about paths under /proc?  then others wouldn't need the
same workaround?

[gavinp, 2013-08-07 22:56:34]

On 2013/08/07 22:30:34, darin wrote:
>
https://chromiumcodereview.appspot.com/22594007/diff/24001/base/process/proce...
> File base/process/process_info_linux.cc (right):
> 
>
https://chromiumcodereview.appspot.com/22594007/diff/24001/base/process/proce...
> base/process/process_info_linux.cc:28: if (!file_util::GetFileInfo(pid_path,
> &file_info))
> maybe the code that complains about GetFileInfo being called on a UI thread
> should avoid complaining about paths under /proc?  then others wouldn't need
the
> same workaround?

/proc/$$/root/tmp/a-real-file or /proc/$$/fd/5 could well be a real file and
subject to jank, so the rule isn't true in general in /proc. I'm more
comfortable looking at these case by case like this and highlighting that you're
doing something scary.

[darin (slow to review), 2013-08-07 23:24:07]

LGTM


On Wed, Aug 7, 2013 at 3:56 PM, <gavinp@chromium.org> wrote:

> On 2013/08/07 22:30:34, darin wrote:
>
> https://chromiumcodereview.**appspot.com/22594007/diff/**
>
24001/base/process/process_**info_linux.cc<https://chromiumcodereview.appspot.com/22594007/diff/24001/base/process/process_info_linux.cc>
>
>> File base/process/process_info_**linux.cc (right):
>>
>
>
> https://chromiumcodereview.**appspot.com/22594007/diff/**
>
24001/base/process/process_**info_linux.cc#newcode28<https://chromiumcodereview.appspot.com/22594007/diff/24001/base/process/process_info_linux.cc#newcode28>
>
>> base/process/process_info_**linux.cc:28: if (!file_util::GetFileInfo(pid_
>> **path,
>> &file_info))
>> maybe the code that complains about GetFileInfo being called on a UI
>> thread
>> should avoid complaining about paths under /proc?  then others wouldn't
>> need
>>
> the
>
>> same workaround?
>>
>
> /proc/$$/root/tmp/a-real-file or /proc/$$/fd/5 could well be a real file
> and
> subject to jank, so the rule isn't true in general in /proc. I'm more
> comfortable looking at these case by case like this and highlighting that
> you're
> doing something scary.
>
>
https://chromiumcodereview.**appspot.com/22594007/<https://chromiumcodereview...
>

[commit-bot: I haz the power, 2013-08-08 19:55:43]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/gavinp@chromium.org/22594007/24001

[commit-bot: I haz the power, 2013-08-08 19:55:51]

Failed to apply patch for base/base.gypi:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file base/base.gypi
  Hunk #1 FAILED at 415.
  1 out of 1 hunk FAILED -- saving rejects to file base/base.gypi.rej

Patch:       base/base.gypi
Index: base/base.gypi
diff --git a/base/base.gypi b/base/base.gypi
index
fef37a1dff35e9586c446c639c60cd1f475c61be..c0bf82041c379b1ba32b3b1855f7df8e0181a875
100644
--- a/base/base.gypi
+++ b/base/base.gypi
@@ -415,6 +415,7 @@
           'process/process_handle_posix.cc',
           'process/process_handle_win.cc',
           'process/process_info.h',
+          'process/process_info_linux.cc',
           'process/process_info_mac.cc',
           'process/process_info_win.cc',
           'process/process_iterator.cc',

[gavinp, 2013-08-08 22:39:49]

+simonjam, we collided on this issue.

I slightly prefer the stat based approach (a lot less mechanism), do you have an
opinion?

[gavinp, 2013-08-08 22:40:25]

On 2013/08/08 22:39:49, gavinp wrote:
> +simonjam, we collided on this issue.
> 
> I slightly prefer the stat based approach (a lot less mechanism), do you have
an
> opinion?

https://chromiumcodereview.appspot.com/21302005 <-- link to simonjam's duplicate
implementation.

[James Simonsen, 2013-08-08 22:53:58]

On 2013/08/08 22:39:49, gavinp wrote:
> +simonjam, we collided on this issue.
> 
> I slightly prefer the stat based approach (a lot less mechanism), do you have
an
> opinion?

I'd done that initially. Julien wanted the stat files, because it's much easier
for the sandbox.

[gavinp, 2013-08-08 22:55:22]

On 2013/08/08 22:53:58, James Simonsen wrote:
> On 2013/08/08 22:39:49, gavinp wrote:
> > +simonjam, we collided on this issue.
> > 
> > I slightly prefer the stat based approach (a lot less mechanism), do you
have
> an
> > opinion?
> 
> I'd done that initially. Julien wanted the stat files, because it's much
easier
> for the sandbox.

sgtm, i'll close this issue.