Refactor ChildProcess and related classes to create a framework outside of br...

Refactor ChildProcess and related classes to create a framework outside of browser/ that supports the following:

- Notification of child process creation/destruction.
- Notification of child process crashes.
- The ability to create and communicate with new child processes.
- Logging of child process communication.

[Marshall Greenblatt, 2010-04-15 22:22:58]

Initial draft of changes, please review.

[jam, 2010-04-15 23:42:08]

I've glanced through the change.  I just don't see enough shared code in the new
files to justify adding the extra layers in Chrome (i.e. to have
PluginProcessHost derive from ChildProcessHost which derives from
base::MpChildProcessHost).  Some of the stuff that's shared is questionable
whether it'll be useful for others, since it seems Chrome specific (i.e.
preventing race conditions when the process is shutting down.  this seems
dependent on the app, since for example we don't need it for renderer/gpu/nacl
processes).  In the end, all that's left is thin layers around the IPC code and
just calling back the embedder.  The multi-process code in Chrome is hard for
new team members to read as is, and I fear this will make it even harder.  So in
this case I would prefer that we don't do this change.

[Marshall Greenblatt, 2010-04-16 02:20:52]

On 2010/04/15 23:42:08, John Abd-El-Malek wrote:
> I've glanced through the change.  I just don't see enough shared code in the
new
> files to justify adding the extra layers in Chrome (i.e. to have
> PluginProcessHost derive from ChildProcessHost which derives from
> base::MpChildProcessHost).  Some of the stuff that's shared is questionable
> whether it'll be useful for others, since it seems Chrome specific (i.e.
> preventing race conditions when the process is shutting down.  this seems
> dependent on the app, since for example we don't need it for renderer/gpu/nacl
> processes).  In the end, all that's left is thin layers around the IPC code
and
> just calling back the embedder.  The multi-process code in Chrome is hard for
> new team members to read as is, and I fear this will make it even harder.  So
in
> this case I would prefer that we don't do this change.

OK, thanks for taking the time to look it over :-)

[jam, 2010-04-16 02:41:28]

Thanks for doing this anyways, and I hope all work is not lost since you can
just use these new classes in your code :)

On Thu, Apr 15, 2010 at 7:20 PM, <magreenblatt@gmail.com> wrote:

> On 2010/04/15 23:42:08, John Abd-El-Malek wrote:
>
>> I've glanced through the change.  I just don't see enough shared code in
>> the
>>
> new
>
>> files to justify adding the extra layers in Chrome (i.e. to have
>> PluginProcessHost derive from ChildProcessHost which derives from
>> base::MpChildProcessHost).  Some of the stuff that's shared is
>> questionable
>> whether it'll be useful for others, since it seems Chrome specific (i.e.
>> preventing race conditions when the process is shutting down.  this seems
>> dependent on the app, since for example we don't need it for
>> renderer/gpu/nacl
>> processes).  In the end, all that's left is thin layers around the IPC
>> code
>>
> and
>
>> just calling back the embedder.  The multi-process code in Chrome is hard
>> for
>> new team members to read as is, and I fear this will make it even harder.
>>  So
>>
> in
>
>> this case I would prefer that we don't do this change.
>>
>
> OK, thanks for taking the time to look it over :-)
>
>
>
>
> http://codereview.chromium.org/1625015/show
>