In IE8 and Chrome, Processes Are the New Threads 397
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.'"
Only one benefit discussed: isolation (Score:3, Informative)
Re:Hilarious... (Score:3, Informative)
As has been mentioned before, this *is* how browsers started. Back in the Stone Age, when the first browsers were created, they were specialized applications that could view one site at a time. In order for you to open multiple pages, you had to start multiple instances of the application, thus multiple processes.
Eventually, it was deemed more efficient to allow a single process to open multiple pages using multiple threads. So, again, this is nothing new, just a reversal to old ideas whose merits are debatable.
-dZ.
Processes in Vista (Score:5, Informative)
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?
Re:Processes in Vista (Score:5, Informative)
The basic reasoning goes that Linux has an awesome processes model because its thread model sucks,
NPTL has scaled to hundreds of millions of threads created in under 10 seconds on common hardware....
Erlang Browser (Score:3, Informative)
Seems like they have taken a leaf of Erlang wisdom here. If you were to write a browser in Erlang, using one (Erlang) process per tab is exactly the way you would have written it. I think it shows that designing software for robustness, something that previously mostly was done for high availability enterprise systems is now reaching the desktop.
Wouldn't surprise me if the next cool browser innovation will be hot code swapping so that you won't have to close all your 5324 tabs just to install the latest browser security fix. At which point they have reinvented Erlang. :)
Re:Chrome = slow as hell (Score:5, Informative)
"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.
Re:Erlang Browser (Score:3, Informative)
It has nothing to do with Erlang and everything to do with basic design principles. Erlang did not invent what it preaches.
Re:Chrome = slow as hell (Score:3, Informative)
Something is wrong with your PC then.
I love FF and have no interest in chrome without all the addons FF provides.
That being said chrome was insanely fast, really, really fast - easily the fastest web browser I've ever seen, including clean instealls of FF1 / 1.5 / 2 and 3.
Re:Requirements/Trade-offs (Score:3, Informative)
A single process (single-threaded or multi-threaded) would have OS limits on the open file/socket descriptors much lower than 100000.
I haven't tried it yet myself but supposedly erlang servers do this kind of thing regularly. Somebody here probably knows if you use ulimit or whatever to tune that.
Re:Processes (Score:5, Informative)
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.)
Re:Requirements/Trade-offs (Score:5, Informative)
"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".
Re:Could someone give the gory details (Score:5, Informative)
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.
Re:Processes (Score:4, Informative)
Re:Processes (Score:4, Informative)
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).
Re:Processes (Score:5, Informative)
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?
Re:Deja vu (Score:3, Informative)
As a minor nitpick, Sleep(0) can return immediately. You'll end up with the main thread burning CPU in a tight loop if nothing is waiting.
Thread.Join would be more appropriate, or using Monitor.* manually.
Re:victory of tabbed browsing - not defeat of thre (Score:3, Informative)
You cannot so isolate threads without effectively making them separate processes. If the threads *can* write into other memory, then there is the danger that broken code *will* do so. What code you write doesn't matter in the least- get a dangling pointer and you'll be writing to something random, which may very well be some other thread's memory space. If the OS doesn't enforce the isolation, you effectively have no isolation.
No code is perfect. The process model is an acknowledgement of that fact. When it comes to plugins, the code is third-party- adobe, etc. Do you really want the stability of the browser as a whole to depend on third-party code?
You acknowledge the security vulnerability possibility, but you seem to be missing that the process model is an example of the sort of sandboxing that is precisely appropriate for limiting the impact of those vulnerabilities. Given sufficient OS-level control, in fact, you could run plugins in subprocesses specifically barred from touching any other portion of the system- that's precisely the sort of the risk-mitigation that we want browsers to be moving toward.
I certainly agree that the process model as currently implemented continues to have some efficiency issues, and the incompleteness of its implementation wrt chrome reusing process and the like impairs or removes some of its benefits. But I'm not sure how it can be held that the segregation and robustness benefits are actually downsides, as you seem to be saying- if Flash crashes or hangs due to a broken flash app, I'd really rather not lose the email I'm writing in another tab.
Re:Requirements/Trade-offs (Score:1, Informative)
You are correct, but using processes would be even worse.
Re:Processes (Score:3, Informative)
Are you kidding? This idea is the subject of a popular, but ignored request for enhancement [mozilla.org] filed back in Mozilla's Bugzilla in 2002!
It has 81 votes and 103 users on CC list. The idea is ages old, the successful implementation is new.
Now if only Mozilla guys got to finally implement it in their browser... Otherwise you'll always get folks blaming the browser for crashes which are in fact caused by proprietary plugins.