Slashdot Mirror
In IE8 and Chrome, Processes Are the New Threads
SenFo writes "To many of the people who downloaded Google Chrome last week, it was a surprise to observe that each opened tab runs in a separate process rather than a separate thread. Scott Hanselman, Lead Program Manager at Microsoft, discusses some of the benefits of running in separate processes as opposed to separate threads. A quote: 'Ah! But they're slow! They're slow to start up, and they are slow to communicate between, right? Well, kind of, not really anymore.'"
Tabs running in separate processes for process isolation for fault/crash tolerance is fine, but its only one benefit. However, 1) tabs running in separate threads shouldn't bring down the entire browser, if the application was properly designed in the first place; and 2) I'm sure we'll still find plenty of ways to crash the primary process and/or cause even separately running processes to do this.
I remember a story from a long time ago, during Longhorn's early development, where Microsoft did a study of the cpu cycles needed for various tasks between WinXP and Linux. I've never been able to track the study down again since, but I remember that creating a new process took about an order of magnitude more cycles on Windows than Linux. Linux processes are also lighterweight in general; Linux admins think nothing of having 100 processes running, while Windows admins panic when it hits 50.
(The basic reasoning goes that Linux has an awesome processes model because its thread model sucks, and Windows has an awesome thread model because its process model sucks. That's why Apache2 has pluggable modules to make it run with either forking or threading.)
A lot of development from the early Longhorn was scrapped, so how does Vista fare? Does its process model still suck?
Not a typewriter
"to load 8 sites" ... 8 sites that you visit frequently and thus have cached on your Firefox installation, perchance?
Don't be so rash to judge. Chrome has many other areas where it lacks compared to Firefox, speed isn't generally one of them. I've heard many users say that it loads pages more than twice as fast as Firefox, and also scrolls much faster on graphical/data-intensive pages.
The lack of extensions (such as adblock, firebug/firephp, flash block, noscript, coloured tabs) is the main reason why I've barely used it since I installed it.
Threads historically were expensive because historically nobody used them. E.g. on Windows IO multiplexing had some history of bugs and didn't worked in the beginning - you had to use threads (and people used to use threads and even now use threads instead of NT's IO multiplexing). On *nix IO multiplexing worked more like always thus threads were (and are) used rarely.
Now, since number of CPUs increased dramatically in recent years, threads were optimized to be fast: developers now throw them as panacea at any task at hand. (Most stupid use of threads seen in the month: start new thread for every child application to wait for its termination; due to stupid code, it still might miss its termination).
As a system developer, I have went trhu user space parts of Linux 2.6 and Solaris 10 threads implementations (in disassembler; x64 and SPARC64 respectively) and can say that they are implemented well. (I was looking for example of atomic ops implementation.) Kernel parts of both Linux and Solaris are well known to perform extremely well, since they were tuned to support extremely large Java applications (and Java only now got IO multiplexing - before that threads were only option to perform multiple IO tasks simultaneously). HP-UX 11.x also didn't showed any abnormalities during internal benchmarks and generally its implementation is faster than that of Solaris 10 (after leveling results using speed of CPUs; SPARC64 vs. Itanic 2).
But I guess "slow *nix threads" is now the myth of the same kind as "slow Windows process creation." (Problem is of course that process creation in Windows would always remains expensive compared to *nix. But not that those millisecons of difference matter much for desktop applications.)
All hope abandon ye who enter here.
"If you're writing a server to handle 100,000 connections simultaneously you probably want to use threads."
Actually, if you want to scale to 100000 connections then you will *not* want to use threads. Google "C10K problem".
I went looking for the same information earlier today. Surprisingly, the design document titled "How Chromium Displays Web Pages" doesn't shed any light on that, at least at this time. You have to dive into the source to find out.
Basically, a single process (the one main browser process) owns the window and draws to it. Renderer processes draw their web content into shared memory; the browser process then transfers the data into a backing store, which it uses to paint the window. The process is coordinated via inter-process message-passing (using pipes, it seems), but the rendering output travels via shared memory.
Actually, threads are heavier in Windows than in every other OS including Linux, MacOSX and Singularity. Still they are way cheaper than a process and that is the whole point of their existence. As for .NET, it uses its own built-in threads model; .NET threads are different than OS threads.
A few onclick events and ajax calls do not make up an application. Something that requires heavy debugging does, and chances are you're reinventing the wheel if that's the case in Javascript (see: jQuery, MooTools, etc).
How are sites slashdotted when nobody reads TFAs?
And, as us old-timers know, this architecture was the basis of the original Bell Labs unix system, back in the 1970s. Lots of little, single-task processes communicating via that newfangled sort of file called a "pipe". That was before the advent of our fancy graphical displays, of course.
Somewhat later, in the mid-1980s when we had graphical displays, the tcl language's tk graphics package encouraged the same design by adding to the usual unix-style pipes and forked processes. The language had a simple, elegant "send" command that would let a sub-process run arbitrary commands (typically function calls) inside the parent process using the sub-process's data. The idea was that you have a main process that is responsible for maintaining the on-screen window(s), but the work is done by the sub-processes. This design prevented blocking in the GUI, because the actions that would block were done in the other processes. The result was a language in which GUI tools could be developed very quickly, and would take maximal advantage of any parallelism supplied by the OS.
But that was all decades ago, before most of our current programmers had ever touched a computer. Imagine if we only knew how to design things that way today. Is it possible that current software developers are rediscovering this decades-old sort of design?
Those who do study history are doomed to stand helplessly by while everyone else repeats it.