On Wed, Feb 4, 2009 at 5:12 PM, cpu wrote:
>
> We don't launch renderers using LaunchApp, we use broker_service-
> >SpawnTarget(). I guess in other platforms that don't have a sandbox
> you can replace that for whatever you want.
>
> You can see BrowserRenderProcessHost::Init() for all the cruft
Hmm, OK, I'll dig further. If ProcessUtil is anyhow not appropriate,
then it probably doesn't make sense to rewire it before looking at how
real renderers would be spawned.
-scott
On Wed, Feb 4, 2009 at 2:12 PM, cpu wrote:
>
> We don't launch renderers using LaunchApp, we use broker_service-
We don't launch renderers using LaunchApp, we use broker_service-
>SpawnTarget(). I guess in other platforms that don't have a sandbox
you can replace that for whatever you want.
You can see BrowserRenderProcessHost::Init() for all the cruft that we
need to launch a renderer, I don't see a good w
+1 for Renderer/PluginLauncher()
+1 for moving IPC out of /chrome/common, in very own library.
Stoyan
On Wed, Feb 4, 2009 at 11:30 AM, Scott Hess wrote:
>
> On Wed, Feb 4, 2009 at 11:10 AM, Thomas Van Lenten
> wrote:
>> On Wed, Feb 4, 2009 at 2:02 PM, Darin Fisher wrote:
>>> On Wed, Feb 4, 20
We talked about moving IPC out of chrome/common, but we should really only
do that if we have a consumer. Right now, it is only needed by Chrome, so
it would seem to be a "premature optimization" to spend time moving it
elsewhere.
-Darin
On Wed, Feb 4, 2009 at 12:35 PM, stoyan wrote:
> +1 for
On Wed, Feb 4, 2009 at 11:10 AM, Thomas Van Lenten
wrote:
> On Wed, Feb 4, 2009 at 2:02 PM, Darin Fisher wrote:
>> On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess wrote:
>>> [Reposting from wrong mailing list, sorry for dupe.]
>>>
>>> On Mac/Linux, IPC::Channel uses socketpairs (or in some cases na
On Wed, Feb 4, 2009 at 11:02 AM, Darin Fisher wrote:
> On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess wrote:
>> On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named
>> pipes), with one end passed through the spawn to the child process.
>> Right now the interfaces don't expose this de
On Wed, Feb 4, 2009 at 2:02 PM, Darin Fisher wrote:
> On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess wrote:
>
>>
>> [Reposting from wrong mailing list, sorry for dupe.]
>>
>> On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named
>> pipes), with one end passed through the spawn to the
On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess wrote:
>
> [Reposting from wrong mailing list, sorry for dupe.]
>
> On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named
> pipes), with one end passed through the spawn to the child process.
> Right now the interfaces don't expose this de
On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess wrote:
> Adam mentioned on the wrong-mailing-list version of this thread that
> it's accepted to wire file descriptors into fixed places. Either way,
> my goal is to make sure that launching Chrome-internal helper tasks is
> distinct from launching arb
10 matches
Mail list logo
