Page 1 of 1

Is it possible to configure multiple sub process paths

PostPosted: Wed Nov 13, 2013 9:11 pm
by sriharshav
Process considerations section describes about multiple processes(Browser process, Render process, Plugin process, GPU process, Utility process). However I see there is only one(&settings.browser_subprocess_path) possibility to set sub process. As I understand the idea is to keep sub process as light as possible.

I am developing an application for Windows platform and I would like to call a C# library. I created a C++/CLI wrapper and tested it.
To achieve this I need to link CLR libraries. I experimented with couple of options.

1. Link CLR to render process and bind CLR interface with V8 bindings in render process
2. Link CLR to browser process and handle via ClientHandler::GetResourceHandler with ajax requests

I feel linking CLR with browser process is not a good idea as any exception in C# will bring down everything.
While linking CLR with render process seems more logical, yet it is making render process slightly heavy.

When I use Canvas elements in page, I see additional render process getting created for graphics support. As this process is not invoking any CLR calls, there is no possibility of a crash due to C# exceptions. Yet I am just wondering if there is a possibility to specify process image for different process types something like &settings.render_subprocess_path, &settings.plugin_subprocess_path so that I link to CLR only for render process.

Re: Is it possible to configure multiple sub process paths

PostPosted: Thu Nov 14, 2013 11:14 pm
by magreenblatt
You can use CefBrowserProcessHandler::OnBeforeChildProcessLaunch to change the executable in the command-line. But there's probably some way to catch CLR exceptions so they don't take down the whole process.

Re: Is it possible to configure multiple sub process paths

PostPosted: Fri Nov 15, 2013 2:01 am
by sriharshav
Thanks for guidance, I will try with your suggestion.

And yes there is an option to catch CLR exceptions, but removing CLR dependency simplifies automated build environment.