Programmatically stop the rendering process

[bioncube]

Hello!

I am using CEF3/1180 with multi-process mode and the multi-threaded message loop.
Windows 7, Visual C++ 2010 Express

I am trying to modify the existing cefclient application so that it displays websites after one another / consecutively. At times, it might happen that the website runs an infinite JS loop like this:

Code: Select all

for (;;) {}

This would obviously never finish loading. If I do

Code: Select all

g_handler->GetBrowser()->GetMainFrame()->LoadURL("http://the-next-website-to-be-displayed.com");

, then the background render process for the document that contains the infinite JS loop will continue using 100% of the CPU and will not be terminated immediately. When the cefclient main window is closed, the bad render process will be closed as well.

Is there a way to programmatically and forcefully terminate the render processes? Similar to how even the render processes that are processing the infinite JS loops are terminated upon closing the cefclient main window. I know

Code: Select all

g_handler->GetBrowser()->GetHost()->CloseBrowser()

is sort of what I am looking for, but this basically invokes the WM_CLOSE on the UI thread, which eventually closes the cefclient window as well. I am looking to keep the cefclient window alive and to kill/terminate/close the browser before I load the next page.

I don't understand the framework too well yet, so any (detailed) help is greatly appreciated!
Kudos to Marshall and other contributors for a robust embedding framework!

[magreenblatt]

Navigating an existing browser to a new URL (like about:blank) may do what you're looking for. If not, we can explore how the Chrome task manager works and perhaps expose a new method.

[fddima]

All depends from your's task. If you want programmatically end (crash) renderer - then better way it is get process ID (PID) of renderer process what host's your's browser and kill process (with many appropriate? ways). I'm agreed with Marshall, it is require investigate code, but as i'm think - maximum what CEF must give about renderer process - it is PID - nothing more. Everything else (killing?) - is trivial on any OS.

[fddima]

Navigating an existing browser to a new URL (like about:blank) may do what you're looking for. If not, we can explore how the Chrome task manager works and perhaps expose a new method.

If i'm rightly understand - it is not have any chance to handle navigation request (may be i'm wrong). But trying navigate to about:blank have sense in most common cases. Thanks.

[bioncube]

Thank you for the help. I have already tried navigating to about:blank and other URLs, but the render process associated with the previous URL is still consuming 100% CPU in the background and doesn't get terminated like render processes normally are terminated when a different URL is loaded.

The only current workaround I have found is to actually kill the child processes of the cefclient with TerminateProcess - this resets the document displayed in the cefclient window to the default startup URL (google.com) and sort of achieves the effect I am looking for. Though I am afraid that using such a brute approach will cause crashes later on, as the TerminateProcess probably doesn't let the render processes clean up properly.

If there are any other ways to achieve this effect of terminating (stray) render processes, I'm all ears!

[magreenblatt]

Terminating the render process is the right approach. The browser process is designed to handle render processes that mysteriously disappear (crashed, killed, etc).

[fddima]

Infinite loop - it is not real case. Infinite loop compiles in real infinite loop. It can't be break safely in any case. I.e. when thread becomes in I/O - it can be interrupted, but when thread doesn't perform any IO - and it is perform nonsense loop - then this thread can be only aborted (killed) - while JS live in renderer process - it can be killed only with entire renderer process. So you are doing all right, may be only you needed to get more precisely of process id's. Note, that one renderer process can host/share many pages (depend's from max renderers processes limit). In general (killing process) - is right.

[bioncube]

I see, that's good to know that terminating the renderer is the correct approach. I can try to get the child process IDs of the current process (cefclient application) and simply terminate them. Or is there perhaps an API that can be used to gather the currently active Render Process IDs?

[magreenblatt]

I see, that's good to know that terminating the renderer is the correct approach. I can try to get the child process IDs of the current process (cefclient application) and simply terminate them. Or is there perhaps an API that can be used to gather the currently active Render Process IDs?

We can expose this API. Killing all child processes may have unintended consequences (for example, you may kill the GPU process or the render process for some other window). Please add an issue to the CEF issue tracker.

[fddima]

I see, that's good to know that terminating the renderer is the correct approach. I can try to get the child process IDs of the current process (cefclient application) and simply terminate them. Or is there perhaps an API that can be used to gather the currently active Render Process IDs?

We can expose this API. Killing all child processes may have unintended consequences (for example, you may kill the GPU process or the render process for some other window). Please add an issue to the CEF issue tracker.

Or better - killing on linux zygote process can give much more harder results.

PS: It is will be good have disable zygote process on linux - it is exists only for consistent updates only (on linux currently loaded modules never locked from disk, so while chrome updates - zygote just keep loaded right versions of libraries, independedly from updates), - it no have any positive startup renderer process time. But it can be affect on chromiums codebase. Currently zygote process doesn't used if renderer prefix used. Yeah, cool words. But really - for our class applications zygote absolutely unwanted and negative process ('cause it is exists, and require even small resources).