Chromium Blog: Responsiveness for Plugins and the Renderer

Chromium Blog

News and developments from the open source browser project

Responsiveness for Plugins and the Renderer

2008年10月10日金曜日

In my last post, I wrote about how we handle I/O in the browser process to keep the main thread of Google Chrome free from hiccups. This time, I'll write about how we keep our sub-processes from interfering with the main ("browser") process.
As you may recall, Google Chrome is a multi-process application, with HTML rendering happening in separate processes we call the "renderers," and plugins running in separate "plugin" processes. Our priority is to always keep the browser process, and especially its main thread, running as smoothly as possible. If a plugin or renderer is interfering with the browser process, the user's interaction with all other tabs and plugins, as well as all the other features of Google Chrome, would also be interrupted. The user might even be prevented from terminating the offending sub-process, negating a key benefit of our multi-process architecture.
The first and most obvious approach is never to block while waiting for information from a renderer process, in case the renderer process happens to be busy or hung. And although the renderers may sometimes synchronously wait for the browser for some requests, there is not an easy way to express that the browser process should wait for the renderer on Windows. Unfortunately, this doesn't cover all cases.
The basic primitive of Microsoft Windows is the "window," which is much more general than just a top-level window with a title bar. Buttons, toolbars, and text controls are usually expressed as sub-windows of a floating top-level window. Windows in this hierarchy are not restricted to single processes, and early versions of Google Chrome used this feature to implement our cross-process rendering architecture. Each tab contained a sub-window owned by a renderer process. The renderer received input and painted into its child window just like any other. The browser and renderer processes each ran their own message processing for things like painting.
A problem arises for some types of Windows messages. The system will synchronously send them to all windows in a hierarchy, waiting for each window to process the message before sending it to parent or child windows. This introduces an implicit wait in the browser process on the renderer processes. If a renderer is hung and not responding to messages, the browser process will also hang as soon as one of these special messages is received. To solve this problem, we no longer allow the renderers to create any windows. Instead, the renderer paints the web page into an off-screen bitmap and sends it asynchronously to the browser process where it is copied to the screen.
Once we made this change, everything ran great. That is, until we implemented plugins. The NPAPI plugin standard that Google Chrome implements allows plugins to create sub-windows, and for compatibility, we can't avoid it. Sometimes a plugin may hang, or more commonly, block waiting on disk I/O. All the hard work we did to insulate the user interface from I/O latency is occasionally undone by our plugin architecture through this long chain of dependencies. To mitigate this problem, we periodically check plugins for responsiveness. If a plugin is unresponsive for too long, we know that the user-interface of Google Chrome might also be affected, and the user might not even be able to close the page that is hosting the plugin. To allow the user to regain control of the browser, we pop up a dialog that offers to terminate the plugin.
If you are doing something that saturates your hard drive (such as compiling Google Chrome), now you know one of the reasons why the interface may occasionally hang and give the "hung plugin" dialog box. Sometimes you may not even realize that a page has loaded plugins when you get this message. You can terminate the plugin immediately, but most of the time it also works to just wait longer for the plugin's I/O to complete.
Posted by Brett Wilson, Software Engineer

Google

ラベル

$200K 1
10th birthday 4
abusive ads 1
abusive notifications 2
accessibility 3
ad blockers 1
ad blocking 2
advanced capabilities 1
android 2
anti abuse 1
anti-deception 1
background periodic sync 1
badging 1
benchmarks 1
beta 83
better ads standards 1
billing 1
birthday 4
blink 2
browser 2
browser interoperability 1
bundles 1
capabilities 6
capable web 1
cds 1
cds18 2
cds2018 1
chrome 35
chrome 81 1
chrome 83 2
chrome 84 2
chrome ads 1
chrome apps 5
Chrome dev 1
chrome dev summit 1
chrome dev summit 2018 1
chrome dev summit 2019 1
chrome developer 1
Chrome Developer Center 1
chrome developer summit 1
chrome devtools 1
Chrome extension 1
chrome extensions 3
Chrome Frame 1
Chrome lite 1
Chrome on Android 2
chrome on ios 1
Chrome on Mac 1
Chrome OS 1
chrome privacy 4
chrome releases 1
chrome security 10
chrome web store 32
chromedevtools 1
chromeframe 3
chromeos 4
chromeos.dev 1
chromium 9
cloud print 1
coalition 1
coalition for better ads 1
contact picker 1
content indexing 1
cookies 1
core web vitals 2
csrf 1
css 1
cumulative layout shift 1
custom tabs 1
dart 8
dashboard 1
Data Saver 3
Data saver desktop extension 1
day 2 1
deceptive installation 1
declarative net request api 1
design 2
developer dashboard 1
Developer Program Policy 2
developer website 1
devtools 13
digital event 1
discoverability 1
DNS-over-HTTPS 4
DoH 4
emoji 1
emscriptem 1
enterprise 1
extensions 27
Fast badging 1
faster web 1
features 1
feedback 2
field data 1
first input delay 1
Follow 1
fonts 1
form controls 1
frameworks 1
fugu 2
fund 1
funding 1
gdd 1
google earth 1
google event 1
google io 2019 1
google web developer 1
googlechrome 12
harmful ads 1
html5 11
HTTP/3 1
HTTPS 4
iframes 1
images 1
incognito 1
insecure forms 1
intent to explain 1
ios 1
ios Chrome 1
issue tracker 3
jank 1
javascript 5
lab data 1
labelling 1
largest contentful paint 1
launch 1
lazy-loading 1
lighthouse 2
linux 2
Lite Mode 2
Lite pages 1
loading interventions 1
loading optimizations 1
lock icon 1
long-tail 1
mac 1
manifest v3 2
metrics 2
microsoft edge 1
mixed forms 1
mobile 2
na 1
native client 8
native file system 1
New Features 5
notifications 1
octane 1
open web 4
origin trials 2
pagespeed insights 1
pagespeedinsights 1
passwords 1
payment handler 1
payment request 1
payments 2
performance 20
performance tools 1
permission UI 1
permissions 1
play store 1
portals 3
prefetching 1
privacy 2
privacy sandbox 4
private prefetch proxy 1
profile guided optimization 1
progressive web apps 2
Project Strobe 1
protection 1
pwa 1
QUIC 1
quieter permissions 1
releases 3
removals 1
rlz 1
root program 1
safe browsing 2
Secure DNS 2
security 36
site isolation 1
slow loading 1
sms receiver 1
spam policy 1
spdy 2
spectre 1
speed 4
ssl 2
store listing 1
strobe 2
subscription pages 1
suspicious site reporter extension 1
TCP 1
the fast and the curious 23
TLS 1
tools 1
tracing 1
transparency 1
trusted web activities 1
twa 2
user agent string 1
user data policy 1
v8 6
video 2
wasm 1
web 1
web apps 1
web assembly 2
web developers 1
web intents 1
web packaging 1
web payments 1
web platform 1
web request api 1
web vitals 1
web.dev 1
web.dev live 1
webapi 1
webassembly 1
webaudio 3
webgl 7
webkit 5
WebM 1
webmaster 1
webp 5
webrtc 6
websockets 5
webtiming 1
writable-files 1
yerba beuna center for the arts 1

Feed

Give us feedback in our Product Forums.

Google
Privacy
Terms

Chromium Blog

Responsiveness for Plugins and the Renderer

ラベル

Archive

Feed