Fix bug in forwarder pid file writing.

Fix bug in forwarder pid file writing.

If we write a shorter creation time than previously, we have to
truncate the file, otherwise the pid will never match. This happens in
the case of rounding. For example:
1415754511.099
1415754511.09

Found this with Dave Tu's help.

BUG=421249, 294878
Committed: https://crrev.com/9d145aaa93ef3142508635858904102784d0ba5f
Cr-Commit-Position: refs/heads/master@{#303843}

[tonyg, 2014-11-12 01:27:38]

tonyg@chromium.org changed reviewers:
+ jbudorick@chromium.org

[jbudorick, 2014-11-12 02:01:34]

Nice catch between the two of you.

https://codereview.chromium.org/716943003/diff/1/build/android/pylib/forwarde...
File build/android/pylib/forwarder.py (right):

https://codereview.chromium.org/716943003/diff/1/build/android/pylib/forwarde...
build/android/pylib/forwarder.py:273: pid_file.truncate()
Is this how we want to fix this? What if we made _GetProcessStartTime return a
consistent string representation of the start time (e.g. 3 digits after the
decimal)?

[jbudorick, 2014-11-12 02:03:33]

https://codereview.chromium.org/716943003/diff/1/build/android/pylib/forwarde...
File build/android/pylib/forwarder.py (right):

https://codereview.chromium.org/716943003/diff/1/build/android/pylib/forwarde...
build/android/pylib/forwarder.py:273: pid_file.truncate()
On 2014/11/12 02:01:33, jbudorick wrote:
> Is this how we want to fix this? What if we made _GetProcessStartTime return a
> consistent string representation of the start time (e.g. 3 digits after the
> decimal)?

Or perhaps we should change how we evaluate for equality above?

[tonyg, 2014-11-12 02:35:09]

On 2014/11/12 02:03:33, jbudorick wrote:
>
https://codereview.chromium.org/716943003/diff/1/build/android/pylib/forwarde...
> File build/android/pylib/forwarder.py (right):
> 
>
https://codereview.chromium.org/716943003/diff/1/build/android/pylib/forwarde...
> build/android/pylib/forwarder.py:273: pid_file.truncate()
> On 2014/11/12 02:01:33, jbudorick wrote:
> > Is this how we want to fix this? What if we made _GetProcessStartTime return
a
> > consistent string representation of the start time (e.g. 3 digits after the
> > decimal)?
> 
> Or perhaps we should change how we evaluate for equality above?

Isn't truncating the most robust solution? It always gets the correct data in
the file. Why would the other approaches be better?

[jbudorick, 2014-11-12 02:39:02]

On 2014/11/12 02:35:09, tonyg wrote:
> On 2014/11/12 02:03:33, jbudorick wrote:
> >
>
https://codereview.chromium.org/716943003/diff/1/build/android/pylib/forwarde...
> > File build/android/pylib/forwarder.py (right):
> > 
> >
>
https://codereview.chromium.org/716943003/diff/1/build/android/pylib/forwarde...
> > build/android/pylib/forwarder.py:273: pid_file.truncate()
> > On 2014/11/12 02:01:33, jbudorick wrote:
> > > Is this how we want to fix this? What if we made _GetProcessStartTime
return
> a
> > > consistent string representation of the start time (e.g. 3 digits after
the
> > > decimal)?
> > 
> > Or perhaps we should change how we evaluate for equality above?
> 
> Isn't truncating the most robust solution? It always gets the correct data in
> the file. Why would the other approaches be better?

You mentioned rounding in the description; I'm wondering if this works when a
number gets rounded up.

Also, what happens if we get a longer creation time than previously?

[tonyg, 2014-11-12 02:44:07]

On 2014/11/12 02:39:02, jbudorick wrote:
> On 2014/11/12 02:35:09, tonyg wrote:
> > On 2014/11/12 02:03:33, jbudorick wrote:
> > >
> >
>
https://codereview.chromium.org/716943003/diff/1/build/android/pylib/forwarde...
> > > File build/android/pylib/forwarder.py (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/716943003/diff/1/build/android/pylib/forwarde...
> > > build/android/pylib/forwarder.py:273: pid_file.truncate()
> > > On 2014/11/12 02:01:33, jbudorick wrote:
> > > > Is this how we want to fix this? What if we made _GetProcessStartTime
> return
> > a
> > > > consistent string representation of the start time (e.g. 3 digits after
> the
> > > > decimal)?
> > > 
> > > Or perhaps we should change how we evaluate for equality above?
> > 
> > Isn't truncating the most robust solution? It always gets the correct data
in
> > the file. Why would the other approaches be better?
> 
> You mentioned rounding in the description; I'm wondering if this works when a
> number gets rounded up.
> 
> Also, what happens if we get a longer creation time than previously?

Sorry, rounding was the wrong explanation. The behavior seems to be that
trailing 0s are omitted. So if something is .09 and the previous was .119, then
the file incorrectly becomes .099. The truncation ensures that we write .09
exactly as returned from the creation time call. We don't have to worry about it
being longer because write() will extend the file. truncate() just truncates to
the current cursor which deletes any old data.

[jbudorick, 2014-11-12 15:03:04]

On 2014/11/12 02:44:07, tonyg wrote:
> On 2014/11/12 02:39:02, jbudorick wrote:
> > On 2014/11/12 02:35:09, tonyg wrote:
> > > On 2014/11/12 02:03:33, jbudorick wrote:
> > > >
> > >
> >
>
https://codereview.chromium.org/716943003/diff/1/build/android/pylib/forwarde...
> > > > File build/android/pylib/forwarder.py (right):
> > > > 
> > > >
> > >
> >
>
https://codereview.chromium.org/716943003/diff/1/build/android/pylib/forwarde...
> > > > build/android/pylib/forwarder.py:273: pid_file.truncate()
> > > > On 2014/11/12 02:01:33, jbudorick wrote:
> > > > > Is this how we want to fix this? What if we made _GetProcessStartTime
> > return
> > > a
> > > > > consistent string representation of the start time (e.g. 3 digits
after
> > the
> > > > > decimal)?
> > > > 
> > > > Or perhaps we should change how we evaluate for equality above?
> > > 
> > > Isn't truncating the most robust solution? It always gets the correct data
> in
> > > the file. Why would the other approaches be better?
> > 
> > You mentioned rounding in the description; I'm wondering if this works when
a
> > number gets rounded up.
> > 
> > Also, what happens if we get a longer creation time than previously?
> 
> Sorry, rounding was the wrong explanation. The behavior seems to be that
> trailing 0s are omitted. So if something is .09 and the previous was .119,
then
> the file incorrectly becomes .099. The truncation ensures that we write .09
> exactly as returned from the creation time call. We don't have to worry about
it
> being longer because write() will extend the file. truncate() just truncates
to
> the current cursor which deletes any old data.

Ah, ok. lgtm

[tonyg, 2014-11-12 15:40:21]

The CQ bit was checked by tonyg@chromium.org

[commit-bot: I haz the power, 2014-11-12 15:41:25]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/716943003/1

[commit-bot: I haz the power, 2014-11-12 16:47:10]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2014-11-12 16:48:03]

Patchset 1 (id:??) landed as
https://crrev.com/9d145aaa93ef3142508635858904102784d0ba5f
Cr-Commit-Position: refs/heads/master@{#303843}