Modifed the content api RenderProcessHostObserver::RenderProcessExited to remove the ununsed & inva…

Modifed the content api RenderProcessHostObserver::RenderProcessExited to remove the ununsed & invalid ProcessHandle parameter

ProcessHandle(pid_t) will be 0 when RenderProcessExited observer API called. There is no use for this parameter to be present as the value is 0 and none of the callers is using this parameter.
BUG=

Committed: https://crrev.com/b419ca564edf8cb1030d1d4205792cf18338495b
Cr-Commit-Position: refs/heads/master@{#299439}

[sramajay, 2014-10-09 11:36:30]

sramajay@cisco.com changed reviewers:
+ lazyboy@chromium.org, sievers@chromium.org

[sramajay, 2014-10-09 11:36:54]

PTAL

[Charlie Reis, 2014-10-09 16:42:01]

creis@chromium.org changed reviewers:
+ creis@chromium.org

[Charlie Reis, 2014-10-09 16:42:01]

Drive-by: Looks like you're missing updates to some test classes, like
render_process_host_browsertest.cc and browser_test_utils.{h,cc}.

If you have try bot access, those would catch that as a compile failure.

[sramajay, 2014-10-10 07:55:58]

I dont have try server access. It is giving exception. Have requested for
access. 

Mean while, i have ran the tests manually. PTAL.

[Charlie Reis, 2014-10-10 16:56:37]

On 2014/10/10 07:55:58, sramajay wrote:
> I dont have try server access. It is giving exception. Have requested for
> access. 
> 
> Mean while, i have ran the tests manually. PTAL.

Ok, I ran some try jobs for you, and it looks like the patch is failing to
apply.  Can you rebase and upload a new patch?

[sramajay, 2014-10-13 10:40:01]

I have Rebased and modified patch.

PTAL.

[no sievers, 2014-10-13 19:00:23]

lgtm

[sramajay, 2014-10-14 05:18:04]

The CQ bit was checked by sramajay@cisco.com

[sramajay, 2014-10-14 05:18:33]

The CQ bit was checked by sramajay@cisco.com

[commit-bot: I haz the power, 2014-10-14 05:19:29]

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

[commit-bot: I haz the power, 2014-10-14 05:27:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-10-14 05:27:04]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[sramajay, 2014-10-14 05:30:10]

Modified AUTHORS file to add my name and email.

[sramajay, 2014-10-14 05:30:37]

The CQ bit was checked by sramajay@cisco.com

[commit-bot: I haz the power, 2014-10-14 05:31:23]

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

[commit-bot: I haz the power, 2014-10-14 06:54:38]

Committed patchset #4 (id:230001)

[commit-bot: I haz the power, 2014-10-14 06:55:59]

Patchset 4 (id:??) landed as
https://crrev.com/b419ca564edf8cb1030d1d4205792cf18338495b
Cr-Commit-Position: refs/heads/master@{#299439}

[Charlie Reis, 2014-10-14 18:43:57]

On 2014/10/14 05:30:10, sramajay wrote:
> Modified AUTHORS file to add my name and email.

The presubmit warning also mentioned signing the CLA, which it doesn't look like
you've completed.  Can you sign that as well?

See
http://www.chromium.org/developers/contributing-code/external-contributor-che...

Thanks!

** Presubmit Warnings **
sramajay@cisco.com is not in AUTHORS file. If you are a new contributor, please
visit
http://www.chromium.org/developers/contributing-code and read the "Legal"
section
If you are a chromite, verify the contributor signed the CLA.

[sramajay, 2014-10-15 05:23:11]

On 2014/10/14 18:43:57, Charlie Reis wrote:
> On 2014/10/14 05:30:10, sramajay wrote:
> > Modified AUTHORS file to add my name and email.
> 
> The presubmit warning also mentioned signing the CLA, which it doesn't look
like
> you've completed.  Can you sign that as well?
> 
> See
>
http://www.chromium.org/developers/contributing-code/external-contributor-che...
> 
> Thanks!
> 
> ** Presubmit Warnings **
> mailto:sramajay@cisco.com is not in AUTHORS file. If you are a new
contributor, please
> visit
> http://www.chromium.org/developers/contributing-code and read the "Legal"
> section
> If you are a chromite, verify the contributor signed the CLA.

I am part of Corporate CLA from CISCO. Could you check the in the Corporate CLA
section?

Thanks.

[Charlie Reis, 2014-10-16 00:00:00]

On 2014/10/15 05:23:11, sramajay wrote:
> On 2014/10/14 18:43:57, Charlie Reis wrote:
> > On 2014/10/14 05:30:10, sramajay wrote:
> > > Modified AUTHORS file to add my name and email.
> > 
> > The presubmit warning also mentioned signing the CLA, which it doesn't look
> like
> > you've completed.  Can you sign that as well?
> > 
> > See
> >
>
http://www.chromium.org/developers/contributing-code/external-contributor-che...
> > 
> > Thanks!
> > 
> > ** Presubmit Warnings **
> > mailto:sramajay@cisco.com is not in AUTHORS file. If you are a new
> contributor, please
> > visit
> > http://www.chromium.org/developers/contributing-code and read the "Legal"
> > section
> > If you are a chromite, verify the contributor signed the CLA.
> 
> I am part of Corporate CLA from CISCO. Could you check the in the Corporate
CLA
> section?
> 
> Thanks.

Confirmed-- thanks!

[Chirantan Ekbote, 2014-10-16 18:47:19]

I'm late to this but I'm writing an observer that does need to know the process
handle.  My only option now is to listen for
NOTIFICATION_RENDERER_PROCESS_CLOSED, which I'd rather not do because I already
know which renderers I care about and I don't want to be spammed with
notifications about the others.

How about instead of removing the handle parameter we either:

1) cache the handle in the function by calling GetHandle() before resetting the
ChildProcessLauncher and then pass it on the notifications OR
2) reset the ChildProcessLauncher after sending out the notifications

What do you think?

[sramajay, 2014-10-17 05:12:19]

On 2014/10/16 18:47:19, chirantan wrote:
> I'm late to this but I'm writing an observer that does need to know the
process
> handle.  My only option now is to listen for
> NOTIFICATION_RENDERER_PROCESS_CLOSED, which I'd rather not do because I
already
> know which renderers I care about and I don't want to be spammed with
> notifications about the others.
> 
> How about instead of removing the handle parameter we either:
> 
> 1) cache the handle in the function by calling GetHandle() before resetting
the
> ChildProcessLauncher and then pass it on the notifications OR
> 2) reset the ChildProcessLauncher after sending out the notifications
> 
> What do you think?

I also had a similar requirement to know the process handle after it exited. but
found that process has been killed before the notification (if we implement the
above proposal, immediately after the notification).

Instead of using the process handle, i started using the RPH::GetID() with which
i am able to achieve the required behavior. Hope this helps.

[Chirantan Ekbote, 2014-10-17 17:57:14]

On 2014/10/17 05:12:19, sramajay wrote:
> On 2014/10/16 18:47:19, chirantan wrote:
> > I'm late to this but I'm writing an observer that does need to know the
> process
> > handle.  My only option now is to listen for
> > NOTIFICATION_RENDERER_PROCESS_CLOSED, which I'd rather not do because I
> already
> > know which renderers I care about and I don't want to be spammed with
> > notifications about the others.
> > 
> > How about instead of removing the handle parameter we either:
> > 
> > 1) cache the handle in the function by calling GetHandle() before resetting
> the
> > ChildProcessLauncher and then pass it on the notifications OR
> > 2) reset the ChildProcessLauncher after sending out the notifications
> > 
> > What do you think?
> 
> I also had a similar requirement to know the process handle after it exited.
but
> found that process has been killed before the notification (if we implement
the
> above proposal, immediately after the notification).
> 
> Instead of using the process handle, i started using the RPH::GetID() with
which
> i am able to achieve the required behavior. Hope this helps.

That doesn't really work for me because I'm doing process management on linux so
I really do need the process handle.  I'll just upload a CL that does (2) so
host->GetHandle() will still be valid.