Simplify an IPC handler which doesn't need _DELAY_REPLY

Simplify an IPC handler which doesn't need _DELAY_REPLY

Committed: https://crrev.com/81366316e1f70c78dde633ae9e24746371a6c14a
Cr-Commit-Position: refs/heads/master@{#322400}

[jam, 2015-03-25 20:51:36]

jam@chromium.org changed reviewers:
+ reveman@chromium.org

[jam, 2015-03-25 20:51:36]

I noticed this while looking through the code for something else.

[reveman, 2015-03-25 20:57:32]

lgtm

https://codereview.chromium.org/1008563003/diff/1/content/common/child_proces...
File content/common/child_process_host_impl.cc (right):

https://codereview.chromium.org/1008563003/diff/1/content/common/child_proces...
content/common/child_process_host_impl.cc:320: // TODO(reveman): Add support for
other types of GpuMemoryBuffers.
FYI, I'll have to change it back to _DELAY_REPLY when fixing this TODO but that
doesn't justify the unnecessary use right now..

[jam, 2015-03-25 22:26:14]

https://codereview.chromium.org/1008563003/diff/1/content/common/child_proces...
File content/common/child_process_host_impl.cc (right):

https://codereview.chromium.org/1008563003/diff/1/content/common/child_proces...
content/common/child_process_host_impl.cc:320: // TODO(reveman): Add support for
other types of GpuMemoryBuffers.
On 2015/03/25 20:57:31, reveman wrote:
> FYI, I'll have to change it back to _DELAY_REPLY when fixing this TODO but
that
> doesn't justify the unnecessary use right now..

oh if you're going to change this, i can close this issue and not land it. I
didn't know that would happen.

[reveman, 2015-03-25 22:31:53]

On 2015/03/25 at 22:26:14, jam wrote:
>
https://codereview.chromium.org/1008563003/diff/1/content/common/child_proces...
> File content/common/child_process_host_impl.cc (right):
> 
>
https://codereview.chromium.org/1008563003/diff/1/content/common/child_proces...
> content/common/child_process_host_impl.cc:320: // TODO(reveman): Add support
for other types of GpuMemoryBuffers.
> On 2015/03/25 20:57:31, reveman wrote:
> > FYI, I'll have to change it back to _DELAY_REPLY when fixing this TODO but
that
> > doesn't justify the unnecessary use right now..
> 
> oh if you're going to change this, i can close this issue and not land it. I
didn't know that would happen.

Either way is fine with me as I'm not sure when I'll have the time to fix this
TODO. Maybe it makes sense to keep it _DELAY_REPLY to be consistent with
RenderMessageFilter, don't now..

[jam, 2015-03-26 15:36:22]

Who sends the IPC that is handled in ChildProcessHost? 

The one in RenderMessageFilter is used for renderer processes. I tried to trace
the other sender of ChildProcessHostMsg_SyncAllocateGpuMemoryBuffer but it kept
going into gpu interfaces and I stopped. Is there any code that needs this in
non-renderer child processes? If so, the gpu interfaces that are implemented in
content/child seem like they're not needed there.

[reveman, 2015-03-26 15:44:00]

On 2015/03/26 at 15:36:22, jam wrote:
> Who sends the IPC that is handled in ChildProcessHost? 
> 
> The one in RenderMessageFilter is used for renderer processes. I tried to
trace the other sender of ChildProcessHostMsg_SyncAllocateGpuMemoryBuffer but it
kept going into gpu interfaces and I stopped. Is there any code that needs this
in non-renderer child processes? If so, the gpu interfaces that are implemented
in content/child seem like they're not needed there.

Ppapi plugin processes.

[jam, 2015-03-26 16:40:59]

On 2015/03/26 15:44:00, reveman wrote:
> On 2015/03/26 at 15:36:22, jam wrote:
> > Who sends the IPC that is handled in ChildProcessHost? 
> > 
> > The one in RenderMessageFilter is used for renderer processes. I tried to
> trace the other sender of ChildProcessHostMsg_SyncAllocateGpuMemoryBuffer but
it
> kept going into gpu interfaces and I stopped. Is there any code that needs
this
> in non-renderer child processes? If so, the gpu interfaces that are
implemented
> in content/child seem like they're not needed there.
> 
> Ppapi plugin processes.

ah, ok, thanks for the explanation.

Thinking about this more, since you don't know when you'll have time to do this,
I'm going to land this. The reason is that I prefer we don't have incorrect
examples in the code.

[jam, 2015-03-26 16:41:02]

The CQ bit was checked by jam@chromium.org

[commit-bot: I haz the power, 2015-03-26 16:41:41]

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

[reveman, 2015-03-26 16:45:07]

On 2015/03/26 at 16:40:59, jam wrote:
> On 2015/03/26 15:44:00, reveman wrote:
> > On 2015/03/26 at 15:36:22, jam wrote:
> > > Who sends the IPC that is handled in ChildProcessHost? 
> > > 
> > > The one in RenderMessageFilter is used for renderer processes. I tried to
> > trace the other sender of ChildProcessHostMsg_SyncAllocateGpuMemoryBuffer
but it
> > kept going into gpu interfaces and I stopped. Is there any code that needs
this
> > in non-renderer child processes? If so, the gpu interfaces that are
implemented
> > in content/child seem like they're not needed there.
> > 
> > Ppapi plugin processes.
> 
> ah, ok, thanks for the explanation.
> 
> Thinking about this more, since you don't know when you'll have time to do
this, I'm going to land this. The reason is that I prefer we don't have
incorrect examples in the code.

totally agree, thanks!

[commit-bot: I haz the power, 2015-03-26 16:46:42]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-03-26 16:47:39]

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