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.'"

Comments

Have to watch what I say

[bigtallmofo]

I may be inadvertently responsible for Internet Explorer 8's use of separate processes for each tab. Months ago, when they invited me to install the beta of their latest web browser, I told them to do something that sounds very similar to "Go fork yourself!"

I think they took that as architectural advice.

Re:Have to watch what I say

[The Ancients]

forkin hell!

Re:Have to watch what I say

[Anonymous Coward]

Wow. This pretty much sums it up and the rest of us have nothing to add.

Re:Have to watch what I say

[gEvil (beta)]

forkin hell!

And here I was hoping I'd see a Spoonerism somewhere.

Re:Have to watch what I say

[Anonymous Coward]

You forkin' sneaky bastage. I'm gonna take your dwork. I'm gonna nail it to the wall. I'm gonna crush your boils in a meat grinder. I'm gonna cut off your arms. I'm gonna shove 'em up your icehole. Dirty son-a-ma-batches.

*cough* http://www.imdb.com/title/tt0087507/

Re:Have to watch what I say

[Wyzardking]

Tomorrow's headline: Anonymous Coward deported to Sweden. Claims he's not from there.

Re:Have to watch what I say

[dwywit]

What, something like hawking fell ?

Re:Have to watch what I say

[omnipresentbob]

A slashdotter seeing something resembling spooning? Never.

Re:Have to watch what I say

[Anonymous Coward]

he's really just calling down the curse of the BSD daemon.

Re:Have to watch what I say

[Anonymous Coward]

The day after tomorrow's headline: Anonymous Coward gets job at IKEA, marry hot sweden blonde with huge rack.

Re:Have to watch what I say

[bigstrat2003]

Fork, fork, fork!

Re:Have to watch what I say

[svunt]

The AC is actually quoting an Italian American character from Johnny Dangerously

Re:Have to watch what I say

[Z00L00K]

No - fork bomb!

But if you have worked in a *NIX environment you have already found out that it's easy to fork a new process and the advantage with processes is that most of the data is local to that process and that you have to explicitly handle interprocess communication. This is what was done before the age of threads.

Threads are easy to create, but they are also dangerous since they can trip eachother heavily by minor programming mistakes. And malicious software often use the weakness of threads in applications.

Re:Have to watch what I say

[tacocat]

I want a shirt that says, "Protect your resources: Fork Off and Die"

Re:Have to watch what I say

[CrazedSanity]

It just goes to show, if ya can't fork it, spoon^H^H^H^H^Hthread it!

Re:Have to watch what I say

[Zwicky]

Something like "Cook my sock" do ya?

Re:Have to watch what I say

[Wyzardking]

As was I. :)

Re:Have to watch what I say

[Gr8Apes]

There is no spoon....

Unless you're The Tick!

Processes

[Ethanol-fueled]

Running each instance in a seperate process is NOT new technology, hell, any n00b who knows what JCreator is has seen that option before(see this comment I posted awhile back).

Increases in computing power have made insignificant the perceived sluggishness of running multiple processes -- if Chrome won't run smoothly on that Pentium 2 of yours, then perhaps you should install command-line linux anyway! :)

Regarding Chrome, check out this response to my comment I linked to above, posted on June 30. At the time, I thought it was just an extension of a good idea but since his comment was posted earlier than Chrome was released I'm beginning to wonder if that fellow had any inside knowledge...

[/tinfoil hat]

Re:Processes

[ergo98]

Running each instance in a seperate process is NOT new technology

Well of course. It isn't even new in the browser world. In fact it's where we started.

The earliest browsers required you to run a new instance for each concurrently opened site. This presented onerous resource demands, so they made it more efficient by having multiple window instances run under one process, and then with tabs that obviously carried over to tabs running under one shared process.

This is so much ado about nothing. I can count on one hand the number of times I've had a problem with Firefox that would have been solved by it being in its own process.

Every bandwagoner, technical lightweight is now stomping their feet that Firefox needs to get on this yesterday, but really this is pretty low on the list of things that make a real improvement in people's lives. In fact I would go so far as to call it a gimmick. Presuming that the sandbox of a browser automatically stops sites from doing stupid stuff (unlike IE that will let a site kill just by going into a perpetual loop in JavaScript), and plug-ins are created by an idiot, this is completely unnecessary.

Chrome's great JavaScript is a real story, one upped by Firefox's ThreadMonkey doing one better. Those are real improvements that really do matter.

Re:Processes

[TheRealMindChild]

Using processes over threads will also benefit when it comes to cluster computing. You can't really migrate a thread to another node, because then you have shared memory coherency issues. However, migrating a process is much easier.

Re:Processes

[7 digits]

> I can count on one hand the number of times I've had a problem with Firefox that would have been solved by it being in its own process.

I restart firefox roughly twice per hour when developing my javascript application. Having 10 concurrent tabs executing heavy javascript/ajax generally hangs the browser.

Of course, extenions (in particular FireBug) are probably responsible of that, and it is painful but not a showstopper. A process per tab model would probably be better for my usage...

Re:Processes

[ThePhilips]

Running each instance in a separate process is NOT new technology [...]

True, *nix does that for last 3 decades.

The point here (and of RTFA) is that finally on Windows processes are becoming cheaper, making them usable for all the nasty stuff *nix was indulging itself for all the time.

On NT 3.5, creation of new process was taking sometime as long as 300ms. Imaging Chrome on NT: if you open three tabs and start three new processes, on NT in the times, that alone would have taken about one second.

Unix never had the problem. It's Windows specific. And they are improving.

Re:Processes

[ShadowRangerRIT]

Not to rain on your parade, but exactly how are you intending to use browsers in cluster computing? Are you expecting to have so many tabs that a full compute cluster is needed to run them? Your post seems to completely forget that we are talking about a web browser!

Re:Processes

[Anonymous Coward]

The process model is desirable even for people who aren't technical lightweights. It vastly simplifies concurrency, because you hand off a lot of the work to the OS using processes instead of threads. The traditional limitation has been that Windows was not very good at quickly spawning lots of processes. UNIX, by contrast, was designed to make doing this very easy, to encourage code reuse and small, chainable tools. I don't know what's changed in the Windows world-- if this particular application domain is not affected by slow spawning, or if there have been improvements in Windows, or if computers are faster, or some combination thereof.

As long as web scripting languages are turing-complete, or at least imperative, we'll never get rid of people doing stupid stuff. So make web browsers robust. Next.

Re:Processes

[Firehed]

javascript application

Well there's your problem...

Re:Processes

[TheRealMindChild]

It is about development practice in general. One day, likely soon, our home/work machine will be a single node on a whole cluster. It would be akin to running a single-threaded app on one of todays multicore cpu desktops.

Re:Processes

[Anonymous Coward]

Cluster computing your browser is pretty unlikely, wouldn't you say?

Re:Processes

[FishWithAHammer]

It's primarily improvements in computer speed. Threads are very cheap in Windows (and this is why .NET in particular is so heavily dependent on spawning tons of threads for many types of tasks) and processes remain fairly expensive, but that expense is somewhat minimized by being about to throw ten kajillion bogomips at the problem.

Re:Processes

[piquadratCH]

Not to rain on your parade, but exactly how are you intending to use browsers in cluster computing?

Didn't you get the memo? The browser is the new operating system! So, naturally, it belongs on a cluster.

Re:Processes

[FishWithAHammer]

Unix still has some pretty gnarly issues with threads being relatively expensive though, no? IIRC, they're nowhere near as cheap as Windows threads (and while you can do anything with processes that you can with threads, I think it's pretty clear that there are some big wins to retaining shared address space instead of doing IPC/shared memory files/whatever).

Re:Processes

[Anonymous Coward]

This is so much ado about nothing. I can count on one hand the number of times I've had a problem with Firefox that would have been solved by it being in its own process.

So I take your overall point and largely agree but I have daily Firefox crashes that take out all tabs and I have to restart the session so there is value in this. I just refuse to use IE when I don't have to because its UI frustrates me and it has the same crashes though they are less frequent. The crash issue is something that this fixes nicely.

Re:Processes

[gnud]

This is so much ado about nothing. I can count on one hand the number of times I've had a problem with Firefox that would have been solved by it being in its own process.

I own a fairly old computer, and every time I open or close a javascript-heavy page, or open a PDF file, all the rest of my tabs become unusable for some seconds. It's not the end of the world, but I can't think of anything that I'd rather firefox devs spend their time on.

Re:Processes

[firefly4f4]

I can count on one hand the number of times I've had a problem with Firefox that would have been solved by it being in its own process.

Possibly you can, but the biggest one I can count is having a flash plug-in (or similar) crash the entire browser when there's only a problem on one tab. That happens more frequently than I'd care for, so if there was a change that only brought down one tab, that would be great.

Re:Processes

[Anonymous Coward]

Today's supercomputer is tomorrow's $299 Dell.

Re:Processes

[AaronLawrence]

Agreed - crashes in the browser itself are rare - Firefox seems very reliable in that way.
However crashes in plugins can be common, and indeed trusting a big binary blob to invasively use your process safely just seems like a bad idea. So I would say that firefox should definitely go for that part and not worry about the process-per-tab part.
Well like most good ideas it has been in Bugzilla for years!
https://bugzilla.mozilla.org/show_bug.cgi?id=156493

Re:Processes

[Tumbleweed]

This is so much ado about nothing. I can count on one hand the number of times I've had a problem with Firefox that would have been solved by it being in its own process.

Every bandwagoner, technical lightweight is now stomping their feet that Firefox needs to get on this yesterday, but really this is pretty low on the list of things that make a real improvement in people's lives.

You've made here the classic mistake of thinking that everyone else uses a piece of technology in the same way that you do. This is not the case. With the advent of tabs, I typically have multiple dozens of them open at any given time. I also often leave programs running for days on end. I surf a LOT of very different sites, most of which I've never been to before, and which often have lots of javascript and/or Flash. This makes for a very different experience than you describe, as I've often had Firefox crash, sometimes without any warning at all, just *poof*, the window is gone without even a warning message. Fortunately, the crash recovery features of FF3 are quite good. But they don't always work, and let me say that having to reopen a browser with several dozen tabs (many of which have youtube videos and whatnot) can take rather awhile.

I very much like the idea of each tab in its own process. Plus, this should work better on multi-core CPUs, which is also quite nice.

Re:Processes

[Anonymous Coward]

Imagine Chrome on NT: if you open three tabs and start three new processes, on NT in the times, that alone would have taken about one second.

It would still be faster than IE.

Re:Processes

[Anonymous Coward]

Of course the new process model doesn't really matter. All this stuff is an improvement, sure, but Google's making a huge deal out of it to disguise the fact that the real reason they want you to use Chrome is that it comes packaged with Gears.

Re:Processes

[EvanED]

It isn't even new in the browser world. In fact it's where we started.

Though it is pretty new for a mainstream browser to choose that as an explicit choice.

I can count on one hand the number of times I've had a problem with Firefox that would have been solved by it being in its own process.

Either you're lucky or I'm unlucky... there was a couple years when I was restarting Firefox probably about once a day on average because the memory use would shoot up to the point where it was basically unusable, and closing tabs basically didn't decrease that use.

It's not nearly that bad now, but I still have plug-ins cause problems from time to time. And there are still times when doing something in one tab will cause the whole browser to freeze for a couple seconds, which gets a bit annoying if you're trying to listen to music or something.

Every bandwagoner, technical lightweight is now stomping their feet that Firefox needs to get on this yesterday, but really this is pretty low on the list of things that make a real improvement in people's lives.

Processes would solve the problems I alluded to first, but they are mostly gone anyway. Threads would help with the second problem. I do not feel that Firefox needs separate processes, but I really *do* feel that it would benefit from separate threads.

(And in terms of the list of things that make a real improvement in people's lives, I would say that web browser improvements have basically stopped fitting that bill anyway. A thread per tab would, I think, be an improvement on par with almost anything FF3 brought to the table. Maybe Mozilla should have not done the awesome bar because that too is low on the list of things that make a real improvement?)

Presuming that the sandbox of a browser automatically stops sites from doing stupid stuff (unlike IE that will let a site kill just by going into a perpetual loop in JavaScript)...

Unfortunately, MS has yet to solve the halting problem. Maybe they should import Mozilla's module that determines if a Javascript loop is going to be perpetual too.

(I'm being somewhat facetious here of course. I do appreciate Firefox's "this script is taking a long time to run" dialog. At the same time, I have definitely gotten that for legitimate scripts.)

Re:Processes

[andy_t_roo]

Twice yesterday i had flash in one of my tabs take down the entire browser -- if firefox had seperate processes for each then it would of saved me a bit of bother.

So, for me, just yesterday uses up half of that "1 hand of problems" that would be fixed with multiple processes.

Re:Processes

[ThePhilips]

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:Processes

[Anonymous Coward]

Didn't you get the memo? The browser is the new operating system! So, naturally, it belongs on a cluster.

So, would that make IE8 a, umm, err, cluster fork?

:-)

Re:Processes

[Blufar]

I got to thinking about Google saying they would add extensions sometime in the near future. My #1 extension I would want is adblock plus or something similiar. But this got me to thinking that they would block everything but google's own ads and ka-ching, they're increasing market share and therefore ad revenue. Somehow, I think this is where they plan on making money from the web browser.

Re:Processes

[Anonymous Coward]

Sounds like you'll need a cluster in order to run the new browsers.

Re:Processes

[xaxa]

Increases in computing power have made insignificant the perceived sluggishness of running multiple processes -- if Chrome won't run smoothly on that Pentium 2 of yours, then perhaps you should install command-line linux anyway! :)

It's not that bad -- my PII (at 366MHz) runs Links2 fine in either X or on the framebuffer. Not having any CSS makes things *really* fast. The other options seem to be Kazehakase (a minimal Gecko-based browser, a little too minimal) or maybe an older Opera (the latest Opera uses too much RAM, as does Firefox and Konqueror).

Re:Processes

[Sentry21]

I suggest that we have every machine set up to run as many tabs as there are CPUs, and then we distribute data out and retrieve the results via AJAX. Bam! Online cluster computing. This is the REAL reason for accelerated Javascript engines.

Re:Processes

[spectre_240sx]

Chrome is doing more than browsers originally did. It's got a master process that's watching over everything else. The processes are also running at multiple different privilege levels. This may not be something that's absolutely new, but it does show innovation. There's nothing wrong with evolutionary progress. So-called "revolutionary" ideas often end up being less useful.

I find that browsers will crash or hang fairly often if a page is poorly coded or a plugin reacts badly. Unfortunately, people will always make mistakes and there will always be things that are capable of crashing a rendering engine, but if separate processes are used, the effects can be limited to the tab / plugin that cause the problem. This opens up a lot of other potential separations. It would be great if they could separate text-boxes from the tab somehow so that if a tab went to hell, one's Slashdot post needn't go with it. Obviously you're not going to see a separate process for each input, but relegating all user-generated state to a process separate from the rendering engine might be a good idea.

I'm having trouble understanding your argument about sandboxing, but it seems that you're for it. Separate processes greatly increase the degree of security in this case. Malicious coders would have to find a vulnerability in both the browser and the operating system to get around what Google is doing. If sandboxing is implemented in the browser alone, there's no operating system security to step in if there is a vulnerability in the browser.

As for the javascript engine... Yes, Firefox's is faster, but it's also more mature. The architecture for V8 has a lot of potential and who knows what kind of speed increases we'll see after further development. Also, There may be reasons other than speed that make a full javascript virtual machine a good way to go. It's good to have competing solutions which drive innovation.

Re:Processes

[smartdreamer]

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.

Re:Processes

[apoc.famine]

Ditto. FF3 on my little Asus EEE can become unresponsive for several seconds at a time as it tries to chew through a few heavy scripts on a few pages.

Let me read slashdot while my radar weather loop loads, damnit!

Re:Processes

[apoc.famine]

Currently that's spelled "half of the internet". The other half is flash.

Re:Processes

[Firehed]

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

[jc42]

Running each instance in a seperate process is NOT new technology

Well of course. It isn't even new in the browser world. In fact it's where we started.

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:Processes

[Varun Soundararajan]

You dont run operating system as the application on the cluster :-). You connect the computers running operating system to harness the computing power of the cluster to run computationally intensive application.

So, you might want to say, "lets connect all browsers running in disparate cores/computers and run the next generation javascript plugin/code that would go infinite loop and clap our hands to say, wow our browsers are the new operating system".

having said all this verbose, the simple slashdot lingo for the above is "Now imagine a boewulf cluster of the same"
Slashdot Lingo - mocking simplified...

Re:Processes

[Johnno74]

Ahh .net threads are regular win32 threads. They are scheduled by the OS, not the runtime. .Net code is (well, can be...) much, much more robust than c++ code as its managed, and type conversion errors, null references and other things can be caught and recovered from more gracefully than C++. This applies to Java too, of course.

Re:Processes

[TheLink]

"It's got a master process that's watching over everything else. The processes are also running at multiple different privilege levels. This may not be something that's absolutely new, but it does show innovation"

Operating Systems do that all the time. Why do you think Microsoft sees Google as a threat? They don't see chrome as "just a browser", they see it as competition for Windows.

Anyway, forking is a good thing and sandboxing even better- using "classic" threads is insane when you're talking about running random 3rd party stuff. There are only a few people in the world who can do threads without bugs.

If your browser design assumes that the coders making apps for the "Browser O/S" are going to get it right, it's not going to last very long.

Mainstream cooperative multitasking is so 1980s.

Re:Processes

[Anonymous Coward]

Flash now works great in Ubuntu. After you do this.

http://ubuntuforums.org/showthread.php?t=789578

Re:Processes

[FishWithAHammer]

Makes sense. I really don't know enough about Unix system internals, but this is very useful. Thanks! :)

Re:Processes

[Elladan]

This is so much ado about nothing. I can count on one hand the number of times I've had a problem with Firefox that would have been solved by it being in its own process.

Funny. Firefox crashes every single day for me, usually 2-10 times per day. If I go to youtube, it's guaranteed to crash within an hour.

It sure would be nice if it didn't crash my entire browser session every single time the current tab crashed (hint: flash. Hint2: Flash.)

I would *@#$@*# kill for a browser that didn't suck quite as horrifically as firefox.

Re:Processes

[afidel]

New Processes are still pretty heavy weight. The average I have seen for Chrome is around 20-30MB with typical content open. I currently have 37 tabs open in Mozilla, that would be a crudload of memory in Chrome, but with Mozilla 3 it's only ~300MB.

Re:Processes

[cryptoluddite]

You've made here the classic mistake of thinking that everyone else uses a piece of technology in the same way that you do. This is not the case. With the advent of tabs, I typically have multiple dozens of them open at any given time. I also often leave programs running for days on end. I surf a LOT of very different sites, most of which I've never been to before, and which often have lots of javascript and/or Flash. This makes for a very different experience than you describe, as I've often had Firefox crash, sometimes without any warning at all, just *poof*, the window is gone without even a warning message

And you've made the classic blunder of starting a land war in Asia... look, when chrome gets plugins and the rest of the 90% features that firefox has which chrome is missing, each process will take a lot more resources. There will be weird kludges where the tabs use protocol buffers to talk to each other and the main process, add-ons that sync between tabs and crash them all when one crashes.

The amount of communication between tabs and main process in order to implement firefox features is probably going to open up lots of security holes also, where you exploit the tab then it's cake to exploit the main process from there. Or 'steal credentials' from other tabs, etc.

The fact is that a crash of a tab is not acceptable even if it is running in a lower security context. Really the only things that should be in a separate process are plugins -- and on linux they already are, via nspluginwrapper. So really, Chrome -- where's the beef?

Re:Processes

[Anonymous Coward]

Yep, try this for an early approach to using multiple processes for an GUI..

http://portal.acm.org/citation.cfm?id=965145.801292&coll=portal&dl=ACM

In places it seemed like the chrome comic was quoting directly from this paper...

Re:Processes

[hedwards]

I don't have many crashes with Firefox. If they're going to waste time on this, a better task would be just moving the flash and such to a separate process where it can crash with dignity.

Rarely do I have sites that crash my browser when I don't have flash support running.

Personally, I'd rather they worked on things which actually make a difference. Like finishing up the javascript optimizations and getting the features they had hoped to get into 3.0 finished up.

Re:Processes

[Chrisje]

The funny thing is that I'm working on a shiny new HP 6910p laptop. The kind with ~6 hrs battery life, a good deal of memory, a fast CPU and even a decent GPU. Everyone goes on and on about how the "cost" to start different processes all the time is no longer significant, but I really noticed the difference. I run FireFox 3 with a whole bunch of plug-ins and a nice skin. That contraption, in spite of the plug-ins, feels quite a bit faster than the Chrome browser does out of the box. I've tested Chrome yesterday, and at the end of 6 hours of work (in which everything did work off the bat, even starting my Citrix apps from a web portal, kudos to that) I concluded that firefox feels leaner and meaner, and went back to it.

One of the major gripes I have is that it feels like FireFox is much quicker with regards to my proxy. We run a proxy configuration script which gives us different settings depending on which office we're in, and in Firefox I never notice the damn thing running. Now in Chrome, whenever I open a new tab, I see the damn thing executing. New process, sandbagging (or whatever you call it)... bah, humbug. I agree with the parent poster. I can count the times when that would have come in handy on the fingers of one hand after 3 versions of firefox on my system, and it makes the experience noticeably slower.

Cut a long story short: I appreciate it's a beta. Come release time I'll give it another whirr. But right now, I don't see what the big hubbub is about save the fact there's another Open Source competitor on the market, which is always good. What is funny is that when you de-install Chrome, a dialogue pops up asking "Are you sure you want to uninstall Google Chrome? - Was it something we said?"

Re:Processes

[donnielrt]

Each tab in a process is huge for me. Please don't presume that just because you've never faced a problem with one tab misbehaving, eating up resources and crashing the browser, nobody else does either.

I don't give a flying fuck whether or not some browser in the past had tabs/windows as separate processes or not. What I care about is the fact that the best browser, at any point in time failed to have all the features I wanted. Chrome's coming damn close.

Accidentally opening a PDF in the browser still almost brings Chrome to its knees (eventually it regains control and asks me if I want to close the Adobe PLUGIN (as opposed to just telling me that it's fucked and wants to restart, or that the tab needs to be closed). Considering that this is a first week beta, I'm awesomely impressed! I'm sure over time Chrome will evolve into a pretty slick and mature browser. I think Google has outdone itself this time.

Re:Processes

[HanoiAnon]

Funny. Firefox crashes every single day for me, usually 2-10 times per day. If I go to youtube, it's guaranteed to crash within an hour.

It sure would be nice if it didn't crash my entire browser session every single time the current tab crashed (hint: flash. Hint2: Flash.)

I would *@#$@*# kill for a browser that didn't suck quite as horrifically as firefox.

Uh... So why are you still using it??

Re:Processes

[Anonymous Coward]

I just set my IE process priority to 'high' and got the same render speed as Chrome, with lower resource usage and better system performance, even when playing video.

Re:Processes

[vidarh]

The ONLY communication I'd like between tabs is shared cookies and possibly bookmarks. In fact, I don't even use the browser bookmarks anymore, so even that isn't needed.

And you are right, the crash of a tab is not acceptable, but it is unrealistic to expect a complex piece of software to ever be bug free. A large part of why we have process separation and memory protection between applications in the first place is because it increases the overall robustness of the system.

Todays usage of browsers is more like running a large number of applications - most of the tabs I leave running for a long time ARE running applications like Gmail and other complex javascript apps - and I want them fully isolated.

There's just no excuse for not isolating them - it's a throwback to the pre-memory protection days when people where whining about how adding memory protection to their operating systems would be so slow and would just be a crutch for developers.

In fact, I'd be perfectly ok with no shared sessions too - just don't force me to use different profiles to start multiple Firefox processes (i.e. bother to implement locking when writing to the bookmarks for example).

Re:Processes

[the_olo]

Corollary: Revamp the plugin architecture so that plugins have to run in a separate process.

I'm beginning to wonder if that fellow had any inside knowledge...

Are you kidding? This idea is the subject of a popular, but ignored request for enhancement 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.

Re:Processes

[Anonymous Coward]

Many window toolkits sort of are designed that way, it is just the braindead windows UI Toolkit which basically enforces a single threaded behavior.

In Java for instance you have the worker threads as a sorf of enforced pattern to shift long running operations into the background while the ui still stays responsive...

Main issue with this approach is that it does not make things easier, but real ui programming never is due to the web of events on the UI you have to keep track of and due to the parallelism you have to introduce one way or the other if you want to keep your application performing well!

Re:Processes

[apoc.famine]

It's not reinventing the wheel if you don't know what the wheel is yet.

Wait...did you expect someone replying to you on slashdot to know what the hell they were talking about?


Well there's your problem...

Re:Processes

[multipartmixed]

> was looking for example of atomic ops implementation.

If you're still looking, IIRC you should take a look in .. jsatomic.[ch] ..? in spidermonkey. Also, APR has sparc assembler atomic ops (again IIRC).

That said, I'm personally happy enough with the functions in atomic.h under Solaris 10 for the time being. But all I use is compare-and-swaps.

Re:Processes

[Tweenk]

Even better would be running just the plugins in separate processes. This way you don't even lose the tab that crashes Flash, only the problematic Flash video.

Re:Processes

[Tweenk]

Is it possible that current software developers are rediscovering this decades-old sort of design?

It's the Windows programmers rediscovering this. It's only now that the high Windows IPC and process management overhead is starting to get negligible on modern machines. Unices on the other hand have very fast IPC and process management, so they could use this approach from the start.

Re:Processes

[firefly4f4]

Can't argue with that. :)

Re:Processes

[redxxx]

Well, there will be third party extensions for it, and those will block google/double clicks stuff. The open source nature of the browser pretty much guarantees it.

If Google created one that only blocked other companies ads, I imagine they would quickly run into issues with the likes of the SEC.

Re:Processes

[Anonymous Coward]

"Yeah. I got the memo. And I understand the policy. The problem is, I just forgot this one time. And I've already taken care of it so it's not even a problem anymore."

http://en.wikiquote.org/wiki/Office_Space

Re:Processes

[Anonymous Coward]

The ONLY communication I'd like between tabs is shared cookies and possibly bookmarks. In fact, I don't even use the browser bookmarks anymore, so even that isn't needed.

So when you adblock a site you don't want your other tabs to also block it? You want greasemonkey to reload its scripts every time you open a new tab? When you have extensions that add new UI elements you want them to be restricted to only the tab's content area? Maybe you do, but I doubt most people will. Extensions are not going to fit will into a process model like that.

And you are right, the crash of a tab is not acceptable, but it is unrealistic to expect a complex piece of software to ever be bug free.

It is unrealistic that a complex software not have bugs, but it is NOT unrealistic that it never crash or be exploited. Those are solved problems.

Re:Processes

[Anonymous Coward]

The same is true in language architecture. It's on a perpetual cycle between interpreted and compiled, now with varying shades between. One generation realizes that the one the older generation was doing was poor for some group of reasons, so they took a different approach, only to get the same problems the predecessors to the older generation dealt with. Then the cycle continues.

My thought is "what's the point?". Aside from the OS maintaining an absolute separation of resources, this is merely threading with more complex inter-process communication work. If written correctly, a single thread crashing or even eating resources should be no worse than a process crashing or eating resources. However, the trade-off in effort is probably roughly equal to go either way.

I've seen some ghastly process-based implementations that were a result of incompetence, too.

Re:Processes

[Elladan]

Because there's no reasonable alternative yet. Konqueror crashes too, and has a lot of trouble making flash work properly. Opera doesn't work well either.

And of course, it's always a pain to have to constantly override the browser ID with whatever bullshit everyone's bozo website requires.

Re:Processes

[RAMMS EIN]

``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.''

Exactly. Threads are kind of a hack to work around heavy processes and inter-process communication. But they introduce their own problems, especially when programming imperatively: suddenly, you have to take into account that your program's state might (will) be modified, without your program code doing that.

Threads and processes have been converging, so that you can now have processes sharing memory, threads having thread-local storage, and processes that aren't expensive to create. Nowadays, I think the difference is along the lines "everything is private by default" (processes) and "everything is shared by default" (threads). The former is easier to program for, and I therefore regard it as a good idea to use processes, rather than threads.

Re:Processes

[Anonymous Coward]

Didn't YOU get the memo? Clusters are called clouds nowadays.

Re:Processes

[prollifik]

I for one would like to have a choice. As far as I know, for a moderate use of tabs, Firefox uses up less memory after all.

Re:Processes

[Free the Cowards]

If they instead put effort into making their JavaScript interpreter properly asynchronous, not only would JS not freeze other tabs but it would also not freeze the same tab that it's running in.

Re:Processes

[Free the Cowards]

"Feel" is a useless measurement. Time it with a clock if you want a meaningful number. If your goal is to just go with whatever feels nicest to you then certainly you shouldn't bother, but you should realize that this doesn't mean you'll be using the app that's actually faster.

Re:Processes

[riceboy50]

Let me read slashdot while my radar weather loop loads

Hah. You must be using the old discussion system.

Re:Processes

[AndyCR]

(hint: flash. Hint2: Flash.) (...) I would *@#$@*# kill for a browser that didn't suck quite as horrifically as firefox.

Firefox isn't responsible for Flash crashing. Put the blame where the blame goes - at Adobe's feet.

Re:Processes

[AvitarX]

More likely it would be something like "annoying ad block"

Where annoying was classified as anything more annoying than their most annoying ad type.

This would somewhat improve the experience for their users, perhaps lessen frustration with adds, not block any of their own, and be far less to get them in anti-competitive trouble.

Re:Processes

[AvitarX]

Don't forget Dillo, which falls between the 2. Simple rendering, but graphical.

So...

[Anonymous Coward]

...his argument that processes aren't really slower than threads anymore is because your processor is faster?

Re:So...

[moderatorrater]

Yep, kind of like how anti-aliasing isn't really slower than straight rendering any more because I've got a better video card.

Re:So...

[InlawBiker]

Yeah, exactly. Why wait for programmers to come up with solid multi-thread code? $150 now gets you a dual-core CPU and 4gb or RAM. Just hope your browser doesn't crash while you're there....

Re:So...

[clodney]

No, his argument is that with a faster processor he no longer has to care that they are slower.

The threshold of caring is subjective. If you are launching a new process to respond to a mouse move message you probably still care that process launch is expensive.

If you are launching a process to create a new tab, something which is governed by human scale time perception, you probably don't care. Especially since almost all the pages you need are already in RAM, so you may not even hit the disk.

Re:So...

[SanityInAnarchy]

The threshold of caring is subjective. If you are launching a new process to respond to a mouse move message you probably still care that process launch is expensive.

It's also technically solveable -- I'm guessing a lot of the reason Unix servers do this so often is because Unix (Linux in particular) is very fast and efficient at forking.

So, given that example: If that's an Erlang process for a mouse move message, I don't care anymore.

Re:So...

[xouumalperxe]

More like "anti-aliased/sub-pixel rendered text is slower than plain rendered text on your standard GUI, but it's fast enough that you can't really notice, so you might as well call it 'as fast as'".

Oblig

[plopez]

"The 70's called...." I can't bring myself to say the rest....

Re:Oblig

[Anonymous Coward]

1990 called, they'd like their joke back.

Re:Oblig

[MobileTatsu-NJG]

"The 70's called...." I can't bring myself to say the rest....

BURN!!!

Re:Oblig

[Sponge Bath]

"The 70's called..."

Dave? Dave's not here man."

Re:Oblig

[VGPowerlord]

Oh, I thought you just ran out of memory. ;)

Re:Oblig

[Anonymous Coward]

"I, for one, welcome..." I can't bring myself to say the rest...

Re:Oblig

[Anonymous Coward]

... they want their joke back.

Re:Oblig

[Anonymous Coward]

2012 called, "HELP!"

Deja vu

[overshoot]

I remember the "processes vs. threads" argument, but last time around wasn't it Microsoft arguing that a threaded process model was superior to an isolated task model like Linux had? Weren't the Linux camp blowing the horn for the superior robustness and security of full task isolation?

My head hurts, I'm confused.

Re:Deja vu

[LWATCDR]

Well the truth it that Chrome might not be as slow under Linux as it is under Windows.
If I remember correctly Windows is really slow at starting a new process while Linux is pretty fast. That was one reason why Apache was so slow on Windows and why they went to threads.

Re:Deja vu

[Anonymous Coward]

Windows people never really understood processes, they cannot distinguish them from programs (look at CreateProcess). They traditionally don't have cheap processes and abuse threads.

In Linux we have NPTL now so there is a robust threads implementation if you need it. I don't thing processes are "superior" to threads (processes sharing their address space) or the other way round. They are for different purposes. If you need different operations sharing a lot of data go for threads I would say.

Re:Deja vu

[Firehed]

Probably, but which one is more stable? They can argue all they want, but the results still speak for themselves.

Obviously it's not impossible that the IE8 team acknowledged this. Not unlike people blasting a politician for changing his stance on an issue from something stupid to something good for the masses. It's like being of the opinion that mysql_query("SELECT * FROM users where id = {$_GET['id']}"); is a good idea - you're still just plain wrong. Sure, you avoid the overhead of calling a mysql_real_escape_string() first, but is the saved overhead worth the security tradeoff? Obviously not.

Granted, the different models of tab/window behavior within an application aren't quite that drastically different from each other, but if you want to boil it down to performance versus stability and security, it's the same basic argument.

And in this case, running each tab as its own process basically acts as free threading thanks to the advent and ubiquity of multi-core systems. It may take a little extra RAM, but that's offset by the parallelization. (Yes, I know that's vastly oversimplified and probably not even that accurate... you get the general idea)

Re:Deja vu

[FishWithAHammer]

Both have pluses and minuses, as with anything. (I won't speak to the Unix model as I am not terribly conversant with it, but I know a good bit about the Windows model of threaded processes.)

A threaded process model has one enormous advantage: you stay within the same address space. Inter-process communication is annoying at best and painful at worse; you have to do some very ugly things like pipes, shared memory, or DBus (on Linux, that is). Using the threaded process model, I can do something like the following (it's C#-ish and off the cuff, so it probably won't compile, but it should be easy to follow):

class Foo
{
    Object o = new Object(); // mutex lock, functionality built into C#
    SomeClass c = new SomeClass();
 
    static void Main(String[] args)
    {
        Thread t = new Thread(ThreadFunc1);
        Thread t2 = new Thread(ThreadFunc2);
        t.Start();
        t2.Start();
        while (t.IsRunning || t2.IsRunning) { Thread.Sleep(0); } // cede time
    }
 
    static void ThreadFunc1()
    {
        while (true)
        {
            lock (o)
            {
                c.DoFunc1();
            }
        }
    }
 
    static void ThreadFunc2()
    {
        while (true)
        {
            lock (o)
            {
                c.DoFunc2();
            }
        }
    }
}

In an isolated task model, this is nowhere near as simple. The problem, though, is that one thread can, at least in C++, take down the whole damn process if something goes sour. (You can get around that in .NET with stuff like catching NullPointerExceptions, but you'll almost certainly be left in an unrecoverable state and have to either kill the thread or kill the program.) The Loosely Coupled Internet Explorer (LCIE) model is forced to use processes to avoid taking everything down when one tab barfs up its lunch.

Re:Deja vu

[shird]

For the majority of local applications, a threaded model is superior. This is because local applications can be "trusted" in the sense they don't need to run each child thread sandboxed etc, so they gain the benefits of greater efficiency without worrying about reduced security. A browser is quite a different beast - it is effectively an OS to run remote "applications" (read: web 2.0 style web sites). So it kind of makes sense to run each as a seperate process.

Windows the OS still runs each application in its own process. So it's not right to compare it to Chrome and argue that it doesn't use seperate processes, because it does - where it counts.

Re:Deja vu

[ratboy666]

Yes, you are correct. Unix started with a process model based on fork() and explicit IPC. Threads were "grafted on" later. It tends to result in more robust software (good multi-threading is HARD).

In Linux a "thread" is a "process", just with more sharing. Thread creation is cheaper in Windows; process creation is cheaper in Linux. I tend to like the isolation that processes offer (multithreading brings with it the joy of variables that can appear to just change by themselves).

There was never any good reason to NOT use multiple processes in a browser, except one. The GUI was "unified" amongst the browser Windows, and it has always been presumed that it would be too difficult to co-ordinate the drawing of multiple browsers. Also, the menu bars and controls would have to assigned to a separate process for each of the browsers. This can be done with an IPC channel, but that code would not have been portable between Unix and Windows at all.

Since process creation was SO expensive in Windows (in days of old), the "thread" or "lightweight thread" approach was used instead (to maximize portability).

It is an amazing testament to Google that they have achieved the multi-process, single UI model (I just don't know how they did the portability part).

Re:Deja vu

[stevied]

I think that's true, or at least it certainly used to be. Because fork() is always creating a clone of an existing process, page tables and the mappings in them can be created "lazily", i.e. when the new process begins to deviate from the parent.

Windows, IIRC (and I've not done Win32/NT development for ages), makes you specify either an executable file or code, data & stack sections to build the new process out of, so if they do do any optimizations, it must be much harder work.

Re:Deja vu

[The Raven]

This is a misunderstanding of the application.

Microsoft said 'Threads are better than Processes for a web server', where you're wasting a ton of resources creating a new process for every CGI script that's run. They were right! Now every major web server supports in-process applications that are created once per server (perhaps with a pool of shared app space) rather than once per request.

Microsoft has never said that all the applications on your computer should run in one thread... that's just crazy talk.

This is simply a decision by Microsoft and Google to treat a browser tab as an application, rather than as a document. Now that web pages do a lot more processing (and crashing), this makes more sense than the old way. There's nothing particularly bad about using threads instead... Firefox is just fine with threads, I see no reason for them to undertake a massive change due to misplaced hype.

It really has to do with how much the processes share. If most of the memory per process could be shared, threads are probably more efficient. If not, processes. I'm no browser architect though, so I'll leave it up to Google, Mozilla, and Microsoft to make their own decisions.

Re:Deja vu

[gbjbaanb]

You can catch exceptions in c++ threads you know, and if you catch SEH exceptions you're catching the same exceptions as .NET apps do. So, its the platform that matters to get such stability, not the programming environment.

IPC is probably the biggest issue with threads v processes. I recall a quick rule of thumb that says if you get 1 million calls per second with in-process calls, cross-process runs at only 1000 calls per second, and RPC/network calls at 100. The cost of moving outside the app is significant. That was a few years back so things may not be quite so bad now with hypertransport buses, and I'm sure it didn't take into account shared memory - but then, shared memory is still memory in both processes and so not as reliable as a named pipe or socket.

You'll also need a cross-process synchronisation object, and they only exist in the kernel so you have the cost of locking that is very high compared to an in-process only lock.

Re:Deja vu

[jefu]

And since a forked process that is essentially just another instance of a "display web page" process may be able to share much of the static code and shared libraries and even some read-only data structures, it should be even better than in the general case. Toss in a few OS optimizations for this case (that currently don't buy much as most unix style processes end up doing "exec" and loading in new code) and it would be better yet.

Re:Deja vu

[rrohbeck]

But the speed at which Chrome and IE8 spawn new processes depends on user interaction. Unless you use something like FF's Linky extension that allows you to open 99 tabs at a time, you won't notice a performance hitch. I don't think you can click faster than your system can start processes - unless it's *really* maxed out and/or paging. Which, BTW, happened to me just yesterday when FF3's VM size approached 1GB (after a week or so.) Killing the process and letting it restore windows and tabs reduced the VM size to 200-something MB.

Re:Deja vu

[Anonymous Coward]

Threads share all memory by default.
Processes share none by default.

Which do you think is more robust?

Re:Deja vu

[FishWithAHammer]

You can catch exceptions in c++ threads you know, and if you catch SEH exceptions you're catching the same exceptions as .NET apps do. So, its the platform that matters to get such stability, not the programming environment.

Go cause a segfault and catch the resulting exception, please. Oh, wait...

(No, signal handling doesn't count, if only because it can't be done on Windows, and if it doesn't work on Windows your web browser has a real tiny market share.)

Re:Deja vu

[LWATCDR]

Chrome seems a lot slower opening tabs to me. Just saying that I see a lag.

Re:Deja vu

[RightSaidFred99]

I would say that if you need to share memory easily and efficiently, then threads are more robust.

Did that conversation go the way you thought it would?

Re:Deja vu

[aspx]

You just defended Microsoft on Slashdot and you got modded +5 Insightful. I will follow you anywhere, O great one!

Re:Deja vu

[abdulla]

You can have a TLS jmpbuf and setjmp at the start of the thread. So when you segfault you can longjmp to a known location and clean up the thread, continuing on. Ofcourse you can't guarantee the state of the program after this unless you limit the functionality of each thread and make some limited guarantees.

Re:Deja vu

[jc42]

Firefox is just fine with threads, I see no reason for them to undertake a massive change due to misplaced hype.

What? I'm running FF 3.0.1 here, and it still has the glaring problem that when one thread goes "busy", all tabs in all FF windows go zombie for the duration. I was expecting better from the hype around FF 3, but it hasn't appeared yet, not on this Mac or on my linux boxes. So I handle it by running multiple different browsers. That way, when all of FF's windows/tabs block, I can switch to SeaMonkey, and when SM's windows/tabs all block, I can switch to Opera, and when ...

I just upgraded FF on my wife's NT and Vista machines, and it has the same problem there. You get the "busy" pointer, try to switch to another FF window - and nothing happens. So much for the vaunted speed of Windows' threads. And it's not just FF; IE is every bit as bad. If all the tabs in all the app's windows block at once, where's the speed?

This problem was one of the main reasons for going with multiple processes connected by pipes on the original unix systems, more than 30 years ago. And the problem is still with us. If you don't want your entire app blocking when one task gets busy, multiprocessing still works, while multithreading works only occasionally, and all too often everything blocks.

I've long wanted the advantages of shared data spaces that threads give you. But if all the threads block, and the experts (or TFM) can't explain how to prevent this, then I go with multiple processes. It doesn't matter how fast threads can run if they are all getting no cpu time.

Re:Deja vu

[SanityInAnarchy]

Toss in a few OS optimizations for this case (that currently don't buy much as most unix style processes end up doing "exec" and loading in new code) and it would be better yet.

Really? Plenty of Unix-style processes, especially servers, do exactly what you're suggesting -- fork a process, but no exec.

Re:Deja vu

[Anonymous Coward]

If you don't want your entire app blocking when one task gets busy, multiprocessing still works, while multithreading works only occasionally, and all too often everything blocks.

Actually, multithreading would work too. Firefox just doesn't to any of that - networking happens on background threads, and there's this one giant UI thread that does everything (including stop-the-world style JS garbage collection, all web page JS, all DOM manipulation, all layout...)

Re:Deja vu

[ozphx]

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:Deja vu

[FishWithAHammer]

I forgot about longjmp, my bad. That said, with longjmp you can come back from it, *sort of*, but as you said, you can't really guarantee program state, and so that's not really very useful.

Re:Deja vu

[Anonymous Coward]

"Screwdrivers are better than hammers".

Threads are better than processes, in some contexts. Processes are better than threads in other contexts. There's no universal solution.

Re:Deja vu

[FishWithAHammer]

You're right, of course. Off-the-cuff and all that.

In my defense, though, it should not, however, return unless everybody else has ceded time, too. So it might make your laptop angry, but other than that it isn't much of an issue. :)

Re:Deja vu

[ozphx]

Yeah its less of an issue on Vista too. IIRC on XP you've blown a whole quanta which can't be given to another thread so the kernel has to give the rest of your slice to a DPC. The 6 kernel can give out partial time slices (and the quanta is smaller) so its less of an issue.

Hrmmm not 100% clear on that actually. I think Russonavich had a good article on it, I might go google it.

Re:Deja vu

[ozphx]

Or possibly "disregard that, I suck cocks". This seems to be the article I remember: http://technet.microsoft.com/en-us/magazine/cc162494.aspx - and its talking about interrupts.

Re:Deja vu

[Anonymous Coward]

It is an amazing testament to Google that they have achieved the multi-process, single UI model (I just don't know how they did the portability part).

A multi-process GUI like that is not hard, at least not under X11. Different processes can open windows that are parts of other windows. One manager process can control the main windows, and map/unmap the tabs as the user switches around. Normally back/forward/etc would need to be sent over IPC, but Google solved that one by moving them below to the tab itself. Basically it's a simple window manager, that manages tabs instead of windows.

I believe the same thing can be done under Windows, but I have no idea how.

As for doing it portable, GUI code is generally not. X11 is different from Windows is different from OSX. However, assuming the above method works on all three OS'es, writing a wrapper library shouldn't be hard.

Re:Deja vu

[Anonymous Coward]

That's not quite true, IIS4/5 were dogs to support because of their threading (IIS5 in high isolation was slightly better). IIS6 is basically lots of processes a.k.a app pools.

The forking servers are fine (well for 95% of people), its the forking per request that was bad. However there where stable work arounds (fastcgi, modperl, java app connectors) before MS came out with a resonable web server.

Re:Deja vu

[chthon]

I seem to remember that with the advent of Windows NT, Microsoft bet heavily upon threads, because at the same time there where also rumors from Intel about threads being the next big thing in computing, as it was easy to balance threads in multiprocessor system. We are talking about the first half of the nineties here.

Re:Deja vu

[radarsat1]

Your example is *way* too simplistic though. You're not doing any sharing of information there, and thus not demonstrating anything that would happen in the real world.

First of all, you have two threads with their entire bodies looping on the same lock. What's going to happen? They are going to run one after the other, making the use of threads completely pointless in this context.

Secondly, in an actual application the real problem is how to share information between the worker threads and the main thread. Passing information to the thread usually isn't too hard -- give it a pointer and then delete your own copy of the pointer, so it's impossible for them to overwrite each other's data structures. Now use the lock to pass data back to the main thread on a queue or something. Fine, that'll work.

But there are lots of situations where passing a whole object off to a worker thread and having it come back when it's done won't cut it. What if the thread needs to calculate some value and give it to the member variable of a shared object? You either lock the object and write it, meaning you need to stick locking code everywhere the shared object is touched, or you use message passing so that the main thread can retrieve the value from a message queue. But then you're essentially using a custom implementation of an IPC mechanism. May as well just use a pipe or socket.

I find, generally speaking, that as threads because more and more useful in an application, the more they start to resemble processes, and the more you start to need to implement mechanisms that resemble IPC. May as well just use real IPC and processes in the first place, since this is what they are designed for, and it is the very reason they were designed to be so cheap and easy (fork(), socketpair()) on Unix in the first place.

After using threads for years and always implementing the same hackish techniques for stopping them from stepping on each other, I think I've decided at this point to never use them any more.

Re:Deja vu

[Anonymous Coward]

How is this insightful? In a *nix environment, threads are technically processes, but all of that is handled by the OS. If you write a multithreaded program in Unix, you don't have to do the IPC yourself, the OS masks it all.

I know the parent said that he doesn't have a knowledge of the Unix way of doing things, but he *is* replying to a post about someone who is commenting on it. The GP wasn't talking about writing forks in your userland apps, he was talking about how the OS handles it.

Re:Deja vu

[IntlHarvester]

There's an animation when a new tab opens, so some of the lag is by design.

Re:Deja vu

[s1a2n3c4e]

Maybe that's why the *nix release of Chrome isn't out yet. They might have had issues with the portability part...

Hmm, interesting

[Anonymous Coward]

so are threads a bit like a conquistador shoe that is too small and stiff? Or a churro cake? Are they delicious? Is this what Bill Gates promised us in that Seinfeld ad? Because that would be cool. Mmm. threads.

QNX and Microkernels have been doing this forever

[flyingrobots]

..and it didn't take dual core or smp to make it fast either.

I've been preaching this for a long time. It's about time we seeing this. We'll see greater stability because of it.

Kevin

Only one benefit discussed: isolation

[michaelepley]

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.

Re:Only one benefit discussed: isolation

[ceoyoyo]

From the other perspective, having used IE in the past, I know how easy it is for a page to open lots of popups. In fact, you could open so many popups that it would crash the browser.

Now that the browser likes opening new processes, an out of control web page can crash my whole OS instead?

Re:Only one benefit discussed: isolation

[FishWithAHammer]

Er, wha? Threads will regularly kill a process when they're in a bad state in any sufficiently complex program, and given how nasty handling the Web can be, it really doesn't surprise me that web browsers crash.

Processes are both easier to use from a developer's point of view (because I assume part of LCIE is a developer-invisible shared memory model) and somewhat safer than just using threads. It's still possible to crash them, of course, but it's harder to crash than when using a threaded-process model

Re:Only one benefit discussed: isolation

[larry bagina]

Properly designed or not, Firefox doesn't release any memory when a tab closes. Chrome does.

Re:Only one benefit discussed: isolation

[Anonymous Coward]

flash crashes firefox for me at least once a day (well, every day I am using flash) in ubuntu.

I'm not sure how firefox is set up in linux as far as processes/threads, but flash definately crashes the entire browser - not just one tab.

Re:Only one benefit discussed: isolation

[stevied]

Regarding (1): Plugins.

To be considered a serious contender, any browser these days has got to be able to run big gobs of other people's native code. Stuffing it in a separate process where it can do only limited damage has to be a win.

Regarding (2): hopefully, the interface between the controller and the renderers is pretty "narrow", which should mean fewer bugs and make it easier to squeeze out any that are found. Plus the stuff that seems (to me) mostly likely to have issues, namely the HTML parsing and rendering, and the Javacript interpretation / compilation, are no longer part of the controlling process.

Re:Only one benefit discussed: isolation

[stevied]

I think Chrome ties the pop-ups to the creating page, and leaves them in the same process. Which isn't to say it can't be fooled ..

Re:Only one benefit discussed: isolation

[Sloppy]

tabs running in separate threads shouldn't bring down the entire browser, if the application was properly designed in the first place

Big internet client applications are never properly designed in the first place.

I don't say that as a cynic; it's just that they are so damn big and pull in so many libraries, etc. When you're writing a web browser, you don't have time to write a GIF decoder, so you're going to use someone else's library. This type of thing happens over and over, dozens of times. You just can't audit all that code. But if there's a buffer overflow bug in just one of those libraries...

What excites me about this multiprocess approach isn't just the fact that we can recover from hung javascript. That's just a populist example. What I look forward to, is the problem getting split up into even more processes, with some of those processes running as "nobody" instead of the user, or some of them running under mandatory access controls, etc.

All that crap will never be fully debugged, so let's acknowledge that and protect against it.

Chrome's sandboxing is just the tip of the iceberg compared to what is possible, but it's a step in the right direction and (dammit, finally!!) has people talking about sandboxing as something to really work on. A thousand programmers all over the internet are going to adopt a trend that just happens to be a good trend. Thank you, Google.

Re:Only one benefit discussed: isolation

[Sancho]

1) tabs running in separate threads shouldn't bring down the entire browser, if the application was properly designed in the first place

Correct, but the key is that applications aren't designed properly in the first place, and even when they are, they often aren't implemented correctly. Would you apply the same argument to your operating system? That properly designed processes shouldn't be able to crash the whole thing? Why bother with protecting processes, then!

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.

Probably. In fact, opening up Chrome and typing "about:%" in the location bar will do it quite well. Still, if we're going to protect users from bad developers, this is not a bad place to start.

Re:Only one benefit discussed: isolation

[Bogtha]

having used IE in the past, I know how easy it is for a page to open lots of popups.

Not any more. Internet Explorer 6+ has included a popup blocker since Windows XP Service Pack 2. In any case, I doubt popups run in their own process, as it would complicate the implementation of window.opener for no good reason.

Re:Only one benefit discussed: isolation

[Anonymous Coward]

The problem with your logic is that it assumes that Microsoft has full control over all of the code that could potentially run within the browser process. This is not true as browser plug-ins such as Flash or the Java runtime are native code loaded within the browser process. In a single process environment if there is a bug in any of the plug-ins then the entire process is possibly subject to failure. Even if the bug does not cause the process itself to crash, it could potentially write to other portions of the process space causing unexpected results. If there is an unexpected failure on a thread the state of the entire process is suspect.

IE8 and Chrome go about plug-in isolation in different ways. In IE8 the plug-in is loaded in the rendering process, whereas in Chrome the plug-in is loaded into a single dedicated plug-in process. In IE8 if you have three tabs open all using the same plug-in and the plug-in fails on one of those pages that tab closes but the other two tabs continue to run. In Chrome if the same situation happens then all three tabs remain open but the plug-in fails across all three. Neither is really better, although Chrome's model currently requires hackery to work as plug-ins have not been designed to be loaded and isolated in such a fashion.

So it's not as simple as claiming that if a browser is written correctly that it should never fail. First, any sufficient complex software will have bugs, and second, any software that loads native plug-ins in-process cannot account for the activity of those plug-ins. The process isolation model handles both.

Re:Only one benefit discussed: isolation

[ceoyoyo]

If the web page writing stuff in memory is a big enough problem that each page needs it's own process to execute in then there's no need to fool it. Just exploit the buffer overrun or whatever to make it run your own code. Now you've got a nice former Chrome process that you can do whatever you like with.

Re:Only one benefit discussed: isolation

[Anonymous Coward]

In both IE8 and Chrome if a site launches a pop-up it is handled by the same renderer process as the parent site. So no, a pop-up bomb wouldn't hose the OS.

Re:Only one benefit discussed: isolation

[ceoyoyo]

And IE is famous for not allowing malicious web sites to do things they shouldn't, of course.

Re:Only one benefit discussed: isolation

[ceoyoyo]

If I can write a web page that can convince your browser to hose it's process then it's quite likely I can write a web page to convince your browser of other things: such as that the user clicked a link. Or that it should ask the filesystem to start sending the contents of your home directory to me.

Re:Only one benefit discussed: isolation

[I'm Don Giovanni]

"However, 1) tabs running in separate threads shouldn't bring down the entire browser, if the application was properly designed in the first place;"

The main difference between threads and processes as far as robustness is concerned is that threads share one address space while each process has its own address space.

So consider the scenario where a tab's web page contains a Flash thingy, and a bug in the Flash plugin causes Flash to inappropriately write all over the browser's memory? How do you *design* against that? At least by using processes rather than threads, Flash is only corrupting the memory of the particular process that's hosting the tab rather than the memory of the browser in general, as would be the case with threads.

"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."

You're right here. There's already a well known bug in chrome that brings down the parent process and therefore all tabs. (It involves typing "evil:%" in the address bar or some such.) But the idea is that the parent process would have much less code than the child processes, and would be easier to be debug free (and it wouldn't host binary plugins by 3rd parties over whose quality control the browser devs have zero control).

Re:Only one benefit discussed: isolation

[jc42]

1) tabs running in separate threads shouldn't bring down the entire browser, if the application was properly designed in the first place; ...

Heh; I think you just pinned down the exact cause of all the problems with threaded apps, though perhaps inadvertently. In most of our computer industry, a "properly designed" application is an interesting hypothetical concept, but in the real world such a thing doesn't exist.

OK, perhaps some apps start off properly designed, and stay that way for even a few weeks. But then management gets wind of it, and imposes top-priority requirements that the sofware developer (note the singular noun) had never heard of. Then management notices that said developer is overloaded and can't possibly get all the new requirements running by last week, so more developers are assigned to the task. There isn't time to teach them all about the app's design; there usually isn't time to teach them anything about the design. So you now have a team of people doing a rush job without any common understanding of the app's design.

This is what usually kills threads-based projects. Every one of the programmers might well have a very good, totally consistent design in their mind. But no two of them are thinking of the same design, and they're all implementing according to their own understanding of the design. It doesn't help that we software guys have dozens of different kinds of terminology for such things, often using the same or similar words with different meanings. And we're always under pressure to produce a deliverable by yesterday.

So no matter how good that one developer's initial design might have been, by the time the software is delivered, there isn't the slightest chance that the delivered product was "properly designed in the first place". It wasn't designed at all "in the first place"; that was a different app that has long since been overridden and radically redesigned by management's change orders.

All our popular browsers were "designed" (and redesigned) by teams of a hundred or more people. Anyone who has ever worked on any significant software project knows what that means. And anyone who has ever worked with threaded code knows what it means for the chances of correct interaction between the threads.

I get the impression that Opera might be the most internally consistent of the current flock of browsers. Anyone know how many hands have been in that source code? And how fast is the number growing? Of course, it's proprietary, so we probably can't know the actual numbers.

Re:Only one benefit discussed: isolation

[Anonymous Coward]

In both IE8 and Chrome if a site launches a pop-up it is handled by the same renderer process as the parent site. So no, a pop-up bomb wouldn't hose the OS.

Source, please.

Re:Only one benefit discussed: isolation

[Anonymous Coward]

Well, given that all of the browsers (IE,Firefox,Opera, Safari and Chrome) have pop-up blockers included or available you shouldn't have had a problem with pop-ups for the last couple of years.

Plus to you shouldn't go to those sites, they'll make you go blind.

Re:Only one benefit discussed: isolation

[Anonymous Coward]

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.

And on unix, for the process of same user, there no isolation. They can send signal to each other (do a kill -9 -1), can read the same files, and even read other process memory via ptrace. They can also abuse of share resource.
Of course there is some chroot or jail, but that need special privilege...

PS : not to say there is a weak process : the primary one.

Chrome = slow as hell

[Xaximus]

I haven't tried IE8, but I uninstalled Chrome 5 minutes after installing it. It took Firefox about 20 seconds to load 8 sites, while Chrome took over a minute. If it's going to be that slow, nothing else matters.

Re:Chrome = slow as hell

[LWATCDR]

I didn't time it myself but Chrome does seem really slow to start a new tab.

Re:Chrome = slow as hell

[B3ryllium]

"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:Chrome = slow as hell

[Anonymous Coward]

Chrome worked nice and quick for me in Linux. See:

http://lizards.opensuse.org/2008/09/04/google-chrome-on-opensuse/

Re:Chrome = slow as hell

[Anonymous Coward]

Never had that problem. To me they opened tabs in the same amount of time. I wasn't timing it but then again if it was taking three times as long I would of noticed.

So maybe you are running low on memory? Are you using Vista or XP? I just figure if you are going to make such bold claims you should be forthcoming with your setup.

Re:Chrome = slow as hell

[ShadowRangerRIT]

Of course, if you are using Firefox with NoScript, AdBlock and/or Flashblock it could be faster. Chrome may have a faster JavaScript engine, but not executing JavaScript is faster than running it no matter how fast your JavaScript engine is.

Re:Chrome = slow as hell

[B3ryllium]

Indeed! So the OP is that much more of a drama queen for uninstalling it in "5 minutes".

Re:Chrome = slow as hell

[The MAZZTer]

Chrome does have problems if you load a large number of sites at once, and specific sites it seems to load very slowly with high CPU usage. These are issues I am sure will be addressed over time.

For me the switch to Chrome was a no-brainer. Chrome starts up and closes instantly, while Firefox takes a few minutes to start up, and a few minutes to close after I close the window. It's probably due to my wealth of extensions, but darnnit, it's 2008, I want the web MY way, AdBlock, NoScript, Stylish, and Greasemonkey at LEAST. I try to "trim down" my extensions but Firefox still loads very very slowly. Even Firefox safe-mode (with no extensions) took longer to start up than it took me to type this sentence. Chrome starts up before I can type a letter.

Re:Chrome = slow as hell

[stg]

I hate the lack of extensions too, but here it's so much faster than Firefox that I'm using it all the time...

Here it takes less time to load Chrome and for it to open an url than for Firefox to open it on a new tab.

I also love the way how it uses so little space for anything other than the site.

Re:Chrome = slow as hell

[AbRASiON]

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:Chrome = slow as hell

[bluej100]

also scrolls much faster on graphical/data-intensive pages

Well, the lack of smooth scroll helps out there. Likewise the ridiculous scroll sensitivity on trackpads. But yes, load times are great.

Re:Chrome = slow as hell

[Anonymous Coward]

Chrome has a lot of shortcomings, but for me its definitely much faster booting up and loading pages, which is enough for me to switch from FireFox for most of my web browsing sessions.

Re:Chrome = slow as hell

[ParanoiaBOTS]

I haven't tried IE8, but I uninstalled Chrome 5 minutes after installing it. It took Firefox about 20 seconds to load 8 sites, while Chrome took over a minute. If it's going to be that slow, nothing else matters.

Maybe its time to retire that p2 300?

Re:Chrome = slow as hell

[I'm Don Giovanni]

I find Chrome to be the fastest browser I've ever used. But maybe it's because the laptop I use it on has 4 gigs of RAM; maybe it's geared toward lots of RAM.

I enjoy using it, but I've gradually gone back to Firefox/IE (which I use interchangeably). One reason is that Chrome's plugin support sucks (Flash applets are herky-jerky and Flash videos stop playing after a few seconds even though the Flash video continues to successfully load; Silverlight applets are quite literally orders of magnitude slower than on IE and Firefox; Photosynth plugin doesn't work; WMP plugin is slow but usable).

Re:Chrome = slow as hell

[Anonymous Coward]

That's pretty interesting, considering about 99% of people say Chrome is very fast. It really is very fast.
 
Maybe you just failed at using it.

Re:Chrome = slow as hell

[wolverine1999]

Is anyone running both like I'm doing?

Re:Chrome = slow as hell

[Anonymous Coward]

My comparison of Chrome and Firefox on graphical/flash intensive pages showed that Chrome was slightly choppy when scrolling, whereas Firefox was smoother.

I decided to stick with Firefox for now because of features and performance, but people need to realize Chrome is in somewhat of a "Beta". I'm sure things will improve along the way as the browser matures.

Re:Chrome = slow as hell

[f()rK()_Bomb]

dude, your doing it wrong =P seriously i dont know how u made chrome that slow

There's another cost to seperate processes

[sqlrob]

AV slowing the start of each process is really going to cause a performance hit.

Re:There's another cost to seperate processes

[Anonymous Coward]

Which is why you would use suDown in limited user mode; to eliminate the need for AV.

Cheap and Dirty Crash Isolation...

[nweaver]

The real reason for processes instead of threads is cheap & dirty crash isolation. Who cares about RPC time, you don't do THAT much of it in a web browser.

But with more and more apps being composed IN the browser, you need isolation to get at least some crash isolation between "apps"

Re:Cheap and Dirty Crash Isolation...

[lgw]

And yet the now-famous :% crash takes down all of Chrome, not just the current tab. I had a chance to ask a Chrome developer about that, but I didn't get an answer. Perhaps crash-isolation isn't as good in practice as one would think, or perhaps that was just another "oops" on the part of the Chrome dev team, and we'll get real crash isolation in the next release.

Re:Cheap and Dirty Crash Isolation...

[Midnight Thunder]

But with more and more apps being composed IN the browser, you need isolation to get at least some crash isolation between "apps"

That is a good point. It should also help reduce the issue of a plug-in or stuck page freezing the whole browser.

One thing I would be curious about is how they handle the inter-process communication since, while they are separate processes, things like cookies need to be shared between them. I would also be curious what sort of memory overhead the causes?

Re:Cheap and Dirty Crash Isolation...

[Kalriath]

Later releases don't do that any more. But I assume that one was because of a crash in the "supervisor process" - IE8 still has the problem of it being possible to crash the supervisor (UI) process and all child processes die with it.

Re:Cheap and Dirty Crash Isolation...

[FishWithAHammer]

Cookies are files. You just have a read/write lock on the cookie directory (or database, if you went that way).

The next step is separate processes for those plug-ins.

Re:Cheap and Dirty Crash Isolation...

[liquiddark]

There's still at least one of those lurking in the latest release - mine died last night.

Re:Cheap and Dirty Crash Isolation...

[larry bagina]

it isn't a strict 1-1 relation between a tab and a process.

• all pages for the same domain are put in the same process.
• frames/iframes all belong to the same process.
• There's a maximum of 20 processes. If you have more tabs, they get added to an existing process.

Re:Cheap and Dirty Crash Isolation...

[Anonymous Coward]

Why doesn't someone just scrap the idea of running "apps" in a program originally designed for viewing documents, and create a new kind of client?

Re:Cheap and Dirty Crash Isolation...

[hindumagic]

Indeed, this is just another step towards having our OS doing the heavy lifting of I/O to the user. Only the core information is passed to the main network and it's coordinating computer - leading to more centralization of information. We're heading into a new stage of the information age, where our data is more centralized and open to access.

This step in providing more robustness in the information delivery platform paves the way for individual apps to run in one browser, and possibly gaining more process, interaction, and/or display control over the browser (for example, what John Carmack has been talking about with Quake Live - it is browser based). You'll have custom applications such as: security interfaces, calendaring, productivity (google apps?), and games (of course). Possibly it will start to be used for important things such as the delivery of medical information, for example the remote control over MRI scans on patients. We can already do our taxes on it. Standardizing the content delivery platform while providing maximum control over the interface is the epitome of a cheap, easy-to-use-and-develop-for information delivery interface. Next step, miniaturize it and improve the interface hardware. Improve on the currently most efficient desk/keyboard/mouse interface.

I believe that the implications of this emerging freedom and centralization of information are important. It's widely open to abuse. Witness China's women's gymnastics team, as a pretty benign example. There is greater access to this information, but it is centrally controlled - and manipulated. Many countries oppress portions of their citizens through controlling the flow of information, and this technology is key to that control. China's great firewall, Burma's, er, Mayanmar's government, Cuba, and the USA's AT%T wiretapping are all different examples of the abuse of the evolution of our information age. But we like our entertainment! The content delivery platform will continue to evolve beyond movies and the current video games. Please keep distracting us. :)

The upside is that we do have these great ways to communicate now - it has changed how we live. Being able to call almost anyone at any reasonable time can radically change how you live. Being able to pay all your bills in five minutes from your own armchair at home is great. Elderly people living normal lives by themselves at home with remote monitoring of their health is great. Anyways, my thoughts on the topic.

Re:Cheap and Dirty Crash Isolation...

[lgw]

Yeah, if reliability were really a goal, any child process could transparantly re-launch the supervisor process (but the architecture would need to provide for that from the beginning). But, hey, it's a desktop app, it's not that hard to start over, and Chrome helpfully offers to re-open all your tabs. Only systems programmers will whine.

Process creation slow??

[Anonymous Coward]

I actually am looking forward to Chrome on Linux. There was an article a few years ago about some changes in the Linux kernel regarding process creation. One of the highlights was how quickly a process could be created, almost as fast as a real thread. This was very old, but it also compared Windows/Solaris process creation and showed how much faster Linux was.

I doubt that

[Just Some Guy]

I imagine that most people who knew what Chrome is and actually installed it also know what processes are.

Re:I doubt that

[Anonymous Coward]

> I imagine that most people who knew what Chrome is and actually installed it also know what processes are.

Not true. I got a call from my mother in law saying Chrome was super slow, and how can she fix it the day after it came out.

I told her just use Firefox for a few more years until Chrome is polished.. I'm not sure she even knows about tabs.

Re:I doubt that

[Altus]

Chrome polish!

Um, it's really a red herring

[Estanislao Mart�nez]

The real issue here is that our OS's mechanisms for controlling resource sharing and protection among cooperating concurrent "lines" of execution (to avoid the words "process" or "thread") aren't as fine-grained as they could be. It's nearly an all-or-nothing choice between everything-shared ("threads") or very-little-shared ("processes"). Processes do get the advantage that the OS allows them to selectively share memory with each other, but threads don't get the natural counterpart, the ability to define their own thread-local memory domains, protected from other threads. A more powerful OS concurrency API would allow you to say exactly what things are shared and which are private to each unit of concurrent execution.

Re:Um, it's really a red herring

[Anonymous Coward]

That maybe true on windoze. Linux has had fine-grained control of resource sharing between processes/threads for ages - clone(), mmap() etc. Modern linux threads are implemented as processes at the kernel level, in fact. The idea that "processes are slow" is windowsitis, like "command lines suck" - windows processes may be slow, the windows command line may suck, but processes or command lines in general don't necessarily suck.

Re:Um, it's really a red herring

[ShadowRangerRIT]

I don't know if an analogue exists for unmanaged Windows code, but AppDomains in .NET seem to bridge the gap you describe. A single process can have multiple threads and multiple AppDomains, and threads operating in separate AppDomains have substantial protection against one another.

Re:Um, it's really a red herring

[Anonymous Coward]

True, here's one blog entry from a guy who used them just for that purpose.

I'll stick with threads thank you.

Re:Um, it's really a red herring

[TopSpin]

aren't as fine-grained as they could be

See clone(2). Every significant resource related to a process is selectable when spawning a new thread of execution. pthread_create() and fork() are both implemented in terms of clone(). You may invent you're own mix of shared or copied bits according to your specific needs.

Naturally the Windows case is far less general. First, clone() is too short. MinimumWindowsAPISymbolLengthIs(12). There is no fork(). This makes porting fun; see perl, cygwin, et al.

The design intent of Google's Chrome is, simply put, scalability. That's why they focus on Javascript performance; the faster that goes the larger the domain of possible applications. Separate processes mean fault tolerance and privilege isolation, important for long lived native operations doing privileged stuff. Ultimately you figure out the browser is sufficient for the entire GUI. When that happens using concurrent processes instead of threads becomes a requirement.

Re:Um, it's really a red herring

[FishWithAHammer]

It's considerably easier to firewall a thread from taking the rest of the process down in .NET when using AppDomains, although it's still a difficult prospect and arguably more difficult to code and debug across AppDomains.

Re:Um, it's really a red herring

[setagllib]

Thread-local storage has been in almost every modern Unix for a long time, including Linux. That is not the problem. Page protection is a hard problem but Xen virtualisation has shown it can be done on many layers, so perhaps it can be done between threads as well. Just don't hold your breath.

Re:Um, it's really a red herring

[ratboy666]

Its easier to start with SysV, and NO threads. If processes need to share memory, they can do so explicitly with SysV IPC. Of course, as soon as you introduce shared memory, you need to introduce semaphores, which SysV IPC also supports.

Works beauty, and is fully supported on Linux (and Solaris and AIX, etc.).

Of course, Windows probably doesn't do it... So its a loser (but I am sure if the program is popular enough, someone will port it).

Re:Um, it's really a red herring

[jmorris42]

> Ultimately you figure out the browser is sufficient for the entire GUI.

As far as Google is concerned the browser is going to become the OS. If one defines Operating System to mean the software that controls the hardware, loads applications and gives those applications access to system resources Chrome and most modern browsers are getting darned close already. Imagine a netbook that boots a thin Linux layer underneath and Chrome where Chrome also acts as the window manager, probably loading up a 'start page' maximized. that provides the now typical netbook simplified UI. Remember that explorer.exe on Windows is just a fancy wrapper around IE on many incarnations, Nautilus and KDE's file manager are also web browsers.

Once a machine has no other visible native apps, the browser is the OS. I can see a day when even the applets in the system tray are browser popup windows running javascript or Java applications. Not sure I like it, but it is coming whether we graybeards like it or not.

Re:Um, it's really a red herring

[ozphx]

Garbage collection not working across an unmanaged boundary? GC doesn't work that way.

Theres a similar issue with COM components referring to .Net COM components which refer back to the COM component.

That guy should perhaps learn to code?

Re:Um, it's really a red herring

[Anonymous Coward]

I looked at clone(2) and didn't see any features that would be useful in Windows except for the ability to have threads in the same process have different current directories. Note that you could write your own fork() in Windows using native system calls, otherwise the POSIX subsystem wouldn't work.

In fact, that's why process creation is so slow on Windows. It actually requires a number of different system calls to create a new process object, create security tokens, create a new thread object, map the executable into its VM, copy file handles, and so on.

dom

victory of tabbed browsing - not defeat of threads

[schwaang]

Tabbed browsing is now so normal that the problem of a crash in one tab bringing down all the others is big deal. On Vista, this problem happens a lot with IE7, and it's *the* single major annoyance for my geek GF on that platform.

Threads truly have their place, but this is a good use of separate processes per tab because it keeps one tab from crashing the others where threads can't achieve that.

It's the Windows job creation scheme

[David Gerard]

It's the Windows job creation scheme mentality applied to OS threading: processes are heavyweight in Windows. "Process-spawning is expensive - not as expensive as in VMS, but (at about 0.1 seconds per spawn) up to an order of magnitude more so than on a modern Unix." More work = more hardware.

Re:It's the Windows job creation scheme

[FishWithAHammer]

WinNT processes are considerably cheaper than they were when that was written in 2002, both because of more efficient code and faster hardware. Still slower than Unix, but the difference is not that great. (Unless you're running a really shitty antivirus, which would slow down process spawning.)

Re:It's the Windows job creation scheme

[David Gerard]

Well, that's good. But I've yet to meet an antivirus I did like. (Scanning on the same instance of the same OS you're trying to protect is an inherently broken idea.)

Re:It's the Windows job creation scheme

[FishWithAHammer]

Avast works well enough. 'Course, if you're a competent user, antivirus is largely unnecessary.

Limitations

[truthsearch]

There are some details to Chrome's sandboxing implementation that limit its security benefits:

- The process limit is 20. Anything requiring an additional process once this limit is reached, such as opening another tab, will be assigned randomly to any of the existing 20 processes.

- Frames are run within the same process as the parent window, regardless of domain. Hyperlinking from one frame to another does not change processes.

There are also some problems where valid cross-site JavaScript doesn't work. Of course it's still only a beta. Some specific details are documented by Google.

Re:Limitations

[jd]

A friend of mine routinely has 400+ tabs open. Assigning them randomly every 20 is going to make the internal logic look like spaghetti. There are extremely few browsers capable of users with such a browsing pattern and if they switch to process tables for tabs, that number is rapidly going to fall. Given my own browsing habits, if I had a monitor large enough to make navigation practical, I'd probably be using somewhere into the hundreds of tabs, and frankly I don't want Linux' process tables to only show browser entries, obscuring everything else. I happen to like "top" showing me ONE entry for the browser. It means there is room for other stuff.

Re:Limitations

[Anonymous Coward]

A friend of mine routinely has 400+ tabs open.

Maybe you should introduce your friend to bookmarks.

Re:Limitations

[corerunner]

In complete seriousness, what reason is there to ever have hundreds of tabs open? I use typically have 2 browser windows per workspace, and up to 4 workspaces, but even with 20 tabs per window that's still only 160 tabs distributed across the equivalent of 8 monitors! How could anyone possibly remember where to find the site he is looking for in 400 tabs? Maybe I'm missing something...

Re:Limitations

[mdmkolbe]

I use bookmarks only for things I want to keep permanently, tabs are where I keep stuff I want to keep temporarily(*).

(*) Temporary may mean multiple months.

Re:Limitations

[recharged95]

"- Frames are run within the same process as the parent window, regardless of domain. Hyperlinking from one frame to another does not change processes."

I wonder if this will cause heahaches to plugins like flash, WMP, VLC and other DirectX / SDL plugins.

Re:Limitations

[Anonymous Coward]

I use bookmarks only for things I want to keep permanently, tabs are where I keep stuff I want to keep temporarily(*).

(*) Temporary may mean multiple months.

Why? Wouldn't it be easier to just put them in bookmark folders?

Re:Limitations

[mdmkolbe]

Why? Wouldn't it be easier to just put them in bookmark folders?

The self justifying/rationalizing answer is (1) so that when I close them, I don't have to also delete them and (2) I find hundreds of tabs easier to look through than hundreds of bookmarks (*) and with tab saver plugins they are (almost) just as safe.

But enough with the self justification. I think it really boils down to one cause, which has no good reason but exists still the same and I'm not planing on changing. I will bookmark a site when I intend to refer back to it at a later time. As such it requires a conscious effort and choice on my part. I end up leaving a tab open when it gets preempted by another mental task. Thus leaving the tab open is a more passive action that happens merely as a consequence of other actions.

A typical example of this happening is if I'm in the middle of reading a good article recently posted on slashdot. That article may have some interesting links that I want to read once I'm finished with the article, but I don't want to forget to read them so with a single middle click each I'll open each of them in a separate background tab as reminders to read them later. Next a colleague swings by to ask if I'm interested in lunch, so I lock my screen and go to lunch. Over lunch we get talking about some ideas that get me thinking so when I get back, I start franticly searching the web for related topics. This often involves a very wide multilevel branching search in which I may have open a dozen tabs on that topic at a time. Most of those are dead ends that I eventually close, but maybe three of them show promise and I need to dig through them some more, but now it's time for class so I lock my screen again and go to class and afterwards home. Next day my tab count is a few more than it was yesterday and the cycle repeats except maybe I review my old tabs to see what I need to finish ... right after I read this nice story just posted to slashdot ;-).

Basically, I end up treating tabs as my TODO list, while bookmarks are my reference list. This is not intentional, but it is the result.

(*) I keep my tab widths just barely wide enough to see the fav icon and with multirow tabs I can easily see a hundred tabs on the screen at the same time while a menu only gets around thirty. (So why not organize them into sub-folders you ask? Because I'm lazy and since these tabs are often so random there often would be no useful organization. But still mostly because I'm lazy.)

Re:Limitations

[donnielrt]

I'm a bit concerned about that 20 process limit. I hope it's hackable in the registry/configuration somewhere.

Re:Limitations

[jonaskoelker]

The process limit is 20. Anything requiring an additional process once this limit is reached [will run in one of 20]

That's probably reasonably sane. You need to do something in that direction, otherwise people can forkbomb you when you visit their page, by repeatedly opening the page in a new window.

I might want to up the limit to my personal value of 2*${maxtabs} since I can probably afford the extra overhead and want the benefits; oh well, would-be-nice != required.

Re:Limitations

[JCholewa]

I work with a decent amount of tabs, too, but instead of doing a horizontal, multi-row bar, I set my tab-bar to be vertical, down the right of the window. That's mainly because I need to see the tab title -- site icons are just not enough, especially since all these /. pages I have open now have the same exact icon.

In Opera, using the Window panel takes away the unnecessary tab graphical glitz and gives a really compact view that allows many more tabs to be shown -- and it's scrollable.

In Firefox, the "Tree Style Tab" extension allows you to organize your currently running tabs in a directory tree style view. If you middle-click on a link, it gets opened as a collapsible branch under the current page. That way, if you had, say, thirty general category of pages that you were currently browsing, and each category had thirty pages in it, you'd basically have nine hundred tabs going, and you can arbitrarily choose which trees are expanded. And it's scrollable, too -- I didn't know that last part until just right now. I usually have only fifty to seventy pages up there at once.

I'm glad somebody out there is crazy as I am. :)

Re:Limitations

[Anonymous Coward]

20 tabs/processes ought to be enough for anybody. :-)

Self flattery gets you nothing

[Nyall]

I noticed immediately, as I'm sure many of you have, that both browsers isolate tabs in different processes

Huh?
You "noticed" this?
All on your own?
Really?

Haven't they been screaming this from the roof tops as why you should give it a try.

Share nothing procesesses

[Safiire Arrowny]

Share nothing processes which communicate via message passing is the future as far as I can tell.

Not only does that do away with most terrible multithreaded programming problems, but it also can let you write an application which does not need to execute all on the same processor or even the same machine, think concurrency, cloud computing, 1000 core processors, etc.

Look up the way Erlang programs work. Actor based programming is pretty sweet after you wrap your head around it.

Re:Share nothing procesesses

[ceoyoyo]

You can do all that with threads and distributed objects too. I actually find distributed computing much cooler when your controller process accepts and executes threads from other nodes. Plus then you've got some code keeping an eye on those jobs.

Re:Share nothing procesesses

[FishWithAHammer]

I agree with you; processes are only really a big win when you're dealing with a framework that can easily fly off the rails. Most native code falls into this category, because you generally can't even try to recover from a segfault/memory access violation, whereas Java/.NET give you the ability to at least attempt recovery. For managed code, though, threads or distributed objects (I prefer the former; they seem cleaner and more logical to me) are the way to go.

Re:Share nothing procesesses

[David Gerard]

Obviously what we need is every tab running as a driver on a Minix microkernel.

Re:Share nothing procesesses

[Shin-LaC]

Note that Chrome uses shared memory, not messages, to pass the rendering output from the rendering processes to the main browser thread. And it's a sound decision, since it gives them the performance they need without giving up stability.

Re:Share nothing procesesses

[ceoyoyo]

I get nervous about native processes that are so unstable that they need to OS to babysit them too. The same situation in interpreted code is crazy. Memory access violations, or crashing due to unplanned overwriting of your own memory, are a big arrow pointing to a security weakness in your code.

Re:Share nothing procesesses

[Cheesey]

Processes help in another way; memory sharing is explicit rather than implicit, so it is easier to maintain cache coherence on a multi-core CPU. You always know that cache coherence is not necessary between two processes, except for the areas of memory that are explicitly shared, because the processes exist in their own memory spaces. Whereas two threads always share the same memory space.

This is not useful in today's SMP systems but it will be needed in the near future since cache coherence algorithms do not scale well.

Re:Share nothing procesesses

[abdulla]

You can still pass data to a process via a message that causes it to crash. Just as with any program, you still need strict validation on the input, which is the same across processes as within a process. You just can't pass invalid pointers and arbitrarily trash memory (hopefully).

Re:Share nothing procesesses

[FishWithAHammer]

Managed code is not interpreted.

As for memory access violations: by far the most common segfault I see is dereferencing a null pointer, which I don't think you can really call a security weakness--just sloppy code.

Re:Share nothing procesesses

[ceoyoyo]

According to the wikipedia definition of an interpreter, managed code IS interpreted.

Interpreter: In computer science, an interpreter normally means a computer program that executes, i.e. performs, instructions written in a programming language. While interpretation and compilation are the two principal means by which programming languages are implemented, these are not fully distinct categories, one of the reasons being that most interpreting systems also perform some translation work, just like compilers.

An interpreter may be a program that either:

1) executes the source code directly

2) translates source code into some efficient intermediate representation (code) and immediately executes this

3) explicitly executes stored precompiled code[1] made by a compiler which is part of the interpreter system

The virtual machine that runs managed code is clearly doing either (3) or (2), depending on the setup. Managed code proponents don't like having the word "interpreted" mentioned because interpreted code has an obsolete reputation for being slow.

If you're sloppy enough to dereference a null pointer here then you're probably sloppy enough to not check a buffer length over there. There are stories every day about a security vulnerability in some program. The ones that get fixed fastest are the ones that are immediately annoying. If it crashes your vaunted browser it's going to get fixed a lot faster than if it just crashes that shady web page you shouldn't be looking at anyway.

Re:Share nothing procesesses

[FishWithAHammer]

Modern managed code, either in the JVM or the CLR, JIT compiles. Calling this interpretation is kind of silly and misleading (and if you really wanted to, you could run a CLR app through ngen.exe or mono -aot, which stores a native code image along with the CIL image, giving you native code startup speed without JIT but allowing reflection and the other niceties of managed code), because in the traditional sense that people actually use it, rather than Wikipedia's definition, an interpreter would be re-interpreting similar code regularly. By that definition, you're correct...but that's a bad definition. ;-)

And I don't disagree that there will be sloppy code--but you seem to be forgetting that most end users can't fix it, and the fastest way to get them back up and running is graceful failure. Yeah, it's less annoying to them. That's the point. The end user's experience is, for a web browser (and most, though obviously not all, other code), the most important thing, and not doing something to improve it under the guise of "getting websites fixed" is shirking the responsibility to provide the end user with the best possible experience.

Re:Share nothing procesesses

[ceoyoyo]

No, it isn't silly calling it interpreted code. It STILL runs in a virtual machine, even if it is compiled to actual machine language for that CPU. The fact that it's running in a virtual machine is what gives it it's secure properties.

When you write code that is inspected and run on your behalf by another program, that's called interpreted. The other program is interpreting your code.

I'm not forgetting that most users can't fix it. You're missing my point. Let me spell it out: it is BAD that the browser can crash gracefully. It is BAD that the users can get up and running again gracefully. Google, Microsoft or whoever wrote the browser has less incentive to fix serious security flaws if they don't cause much of a problem.

If your browser is crashing all the time, use another browser or scream until the maker fixes it. Everybody should do the same thing if individual tabs crash, but they WON'T and that's BAD.

Re:Share nothing procesesses

[FishWithAHammer]

I missed no point when reading your half-baked idea; your point is simply a poor one. The end user experience is head-and-shoulders above all other issues in importance. There are times when crash bugs are in the "yeah, it'd be nice if we could fix it, but we don't have the time" category, and in the real world people have deadlines. Seamless recovery turns what would otherwise be often-annoying problems into "meh" problems for the only people who matter: the end users. If you can alleviate problems, you do it, even if it's not a complete fix, because your end users want as seamless a product as can be made and your job is to cater to them. If you aren't doing as good a job at catering to the end user as the next guy, you will and deserve to fail.

Hasn't Windows taught you anything? It only has to be good-enough and simple enough to bring back to life when it screws up. That's it. Seamless recovery makes this process far simpler and far more effective.

And if you think all crash bugs are security flaws based on the logic you've expressed above ("if X, then I might as well assume Y without any proof" is pretty shitty), I am very glad I don't work with you.

Re:Hilarious...

[dzfoo]

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

[hardburn]

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

[bluefoxlucid]

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....

Re:Processes in Vista

[dedazo]

The process model in Vista is no different than in XP.

And yes, *nix is generally process-oriented while NT kernels have always favored threading. Having written lower-level software for both platforms (ie daemons/services but not drivers and things like that) I cannot honestly see the benefits of one over the other for most processing-type scenarios, though I assume that there are types of applications that do benefit from a specific model.

Re:Processes in Vista

[FishWithAHammer]

WinNT processes are still slow, but a lot faster than they used to be. I don't have numbers offhand, but processes are not as expensive as they used to be (and you've got better hardware, too).

Re:Processes in Vista

[onefriedrice]

I don't know about the study you're referring to, but Linux's threading model is virtually the same as its process model, only even more is shared from the 'parent' process. This is true for pretty much any unix. Both processes and threads are very lightweight. I won't say its impossible since I don't have much experience with Windows' native threads, but I suspect it's not any better than the *nix implementation. I'd need to see some benchmarks to know for sure, since the Windows source isn't available.

Re:Processes in Vista

[IWannaBeAnAC]

For a long time it used to be that creating a thread in NT was slower than creating a process in Linux. This probably isn't true anymore for recent Windows kernels. But I vaguely remember reading something about some Windows mechanism that amounts to a 'light-weight thread', to try and overcome this penalty. I can't remember what they called it, and it seems to be hard to search for.

There is an interesting discussion at http://blog.extracheese.org/2008/05/processes-spawn-faster-than-threads.html lots more benchmarks for various systems in the comments. For some OSX systems, it seems that spawning threads is slow, and also some comments suggest on some Linux systems also (perhaps pre-NPTL?). But Python threads are bound to one processor, so many of those results are due to running the benchmark on multi-core machines (the 'process' benchmark uses all of the cores, the 'thread' benchmark uses only one).

Re:Processes in Vista

[Johnno74]

You are right about win32 processes being much more heavyweight than unix processes, but your numbers are a bit off. My desktop machine here (vista) has 87 processes running at the moment with my usual dev stuff open (2.5gb memory committed). There is also just over 1000 threads.

Server processes in unix often fork the process to handle a new client request, but in Win32 normally you create a new thread - Or more usually you pick a thread from the thread pool to do the work.

I've seen windows servers with well over 100 processes.

Re:Processes in Vista

[Breakfast Pants]

Anything that garbage collects is going to incur massive copy-on-write damage with forked processes, but do just fine with threads.

Re:Processes in Vista

[Anonymous Coward]

But I vaguely remember reading something about some Windows mechanism that amounts to a 'light-weight thread'

Fibers. They kinda stretched the metaphor a little there...

Re:Processes in Vista

[brezel]

I've seen windows servers with well over 100 processes.

100 processes for a server is _nothing_. i wonder what kind of servers we are talking about. i just checked on our application- and database servers and almost all of them have > 400 processes and well over 500 threads running. and right now where i live it is night and there are hardly any customers on our servers. (yes we run linux)

Re:Processes in Vista

[Anonymous Coward]

I'm not sure. I'm still booting up Vista. I'll let you know in a couple hours.

IPCommunications overhead?

[Urban Garlic]

Having gotten several gray hairs from debugging thread-lock issues, I can't help but wonder how these processes do IPC. Presumably complex objects (in the OOP sense) have to be serialized and written to files or piped through sockets. That's not necessarily a bad idea, but it means the data pathways are exposed to the OS, and it's a potential security issue, too.

Re:IPCommunications overhead?

[FishWithAHammer]

Anything that's sensitive is almost certainly restricted to its own process. If it wasn't a share-nothing model, I'd be shocked.

Thread-locking isn't that hard, however...unless you were doing it in C or something equally abortionate.

Re:IPCommunications overhead?

[Anonymous Coward]

Having gotten several gray hairs from debugging thread-lock issues, I can't help but wonder how these processes do IPC. Presumably complex objects (in the OOP sense) have to be serialized and written to files or piped through sockets. That's not necessarily a bad idea, but it means the data pathways are exposed to the OS, and it's a potential security issue, too.

They use named pipes (which work like special files on NT) and use the standard security descriptors of NT on them. Basically they pass the I/O pipe to the forked child and let it use the pipe like a normal socket for IPC. (You were right, they serialize objects).

Re:IPCommunications overhead?

[Anonymous Coward]

Type `ipcs` in your console and you won't get a list of pipes and files but semaphores, messages queues and shared memory segments. No need for pipes or data serialization in IPC if there's a faster way to share data between processes.

Re:IPCommunications overhead?

[Urban Garlic]

C++, which is more abortionate, not equal. Plus I was retrofitting threading into existing software. I got better.

Re:IPCommunications overhead?

[lamapper]

...(You were right, they serialize objects).

I was wondering, not trolling, this is an honest curiosity based on a past experience I had (explained after question for edification purposes)

The Question/Wondering:

Are there any other bottle necks that would create a FIFO (First in First out) serialized scenario regardless of whether you are using threads or processes? A Singe CPU (Processor vs dual CPUs)? The path to/from the CPU, Graphics processor, CRT Screen or Memory? The Path to/from the NIC (Network Interface Card) or WiFi? etc...

A story from my past where this issue came up as edification:

I was doing some contract SQL programming work for a telecommunications company. The company was utilizing IBM's OS/2 Operating System and OS/2's Database Manager for processing SQL queries.

The manager authoritatively stated that OS/2 was multi-threaded and multi-tasking so that no matter how many queries were sent, the smallest and fastest would finish first, then the next smallest and so on and so forth; until the largest/longest query finally finished. I was publicly scoffed at when I told the manager, based on my experience, that was not true. I was told who did I think I was. I explained that I had read a white paper written by the IBM Engineer that had designed and coded the Database Manager Engine where he stated that it was a FIFO model.

The manager still did not believe what I was stating and rather then argue, I offered a simple test case. Fortunately for me the manager agreed or I might have been looking for my next contract sooner rather then later. I submitted three SQL queries, one requesting hundreds of thousands of records from multiple databases, on requesting just a few pieces of information from a single database and another medium size query. I submitted the largest query first, the shortest second and the medium last.

The manager assumed the shortest query would finish first.

Even after the second smaller query did not finish until after the larger first query the manager refused to believe the results.

Even though IBM advertised and marketed OS/2 to be able to run multiple processes and tasks concurrently, the database engine could not. Therefore the database engine was the bottle neck in this scenario.

My question is is there a bottle neck that would prevent any browser (Chrome, IE-the-next-one, FireFox, Opera, Safari, Konqueror, etc... (or any of the other 19+ browsers...)) from running either processes or threads concurrently? A bottle neck that would 'serialize' the request regardless how the browser implemented this?

What about any of the following within the computer. The data bus? The CPU (single vs dual CPUs)? NIC Cards? WiFi? Any data path related to or other then the computer's data bus? Note: in one of these responses, a slashdotter mentioned that the child of a parent would be sand boxed with the same processor, even if the computer had more then one processor...that was interesting and informative, thank you!

I honestly don't know and welcome reading from anyone who does.

Re:victory of tabbed browsing - not defeat of thre

[Anonymous Coward]

IE7 on Vista? Is she a Microsoft geek, then?

Slow to start a process!?

[Sloppy]

They [processes] 're slow to start up

It's hilarious anyone would think that. We're talking about a web browser, not a web server. Even on platforms where process creation is "slow", it's still going to be instantaneous from a single human's point of view. It's not like the user is opening 100 tabs per second.

Re:Slow to start a process!?

[ShadowRangerRIT]

Reading a number of the prior posts, it looks like Windows process creation has overhead of roughly a tenth of a second. That's slow enough to be visible to the naked eye (barely). If that's roughly synchronous per core and I open up a multitab bookmark (say, 30 webcomics) that means the time taken simply to launch the processes on a dual core machine would be roughly 1.5 seconds. That doesn't count any setup work Chrome has to do after the process is created, it's just the OS overhead cost. That's non-trivial.

Re:Slow to start a process!?

[Anonymous Coward]

open up a multitab bookmark (say, 30 webcomics) ...the time taken ...roughly 1.5 seconds. ... That's non-trivial.

Non-trivial from a utterly pointless geek point of view.

I don't know how you make a living, but where I work the time it takes to open all the PHB emails with powerpoint attachments is a far greater time waster than the time it takes to open 30 webcomics.

You don't have a spouse if you read 30 webcomics in the evening.

Re:Slow to start a process!?

[Just Some Guy]

That's non-trivial.

1.5 seconds to open 30 tabs, especially when compared with how long it'll take just to fetch their contents, is indeed trivial.

Re:Slow to start a process!?

[FishWithAHammer]

This really is important to remember. WinNT processes *are* slow, but not *that* slow anymore. (In the NT 3.5 days, on the other hand, a process could take tenths of a second to start up.)

Re:Slow to start a process!?

[Joe Snipe]

It's not like the user is opening 100 tabs per second

Apparently you haven't met my grandmother.

Re:Slow to start a process!?

[Jenos]

well I do open 75 tabs at once for my morning webcomics though..."Open All in Tabs" has changed my life.

Re:Slow to start a process!?

[smallfries]

I can't see which prior posts you're pulling that from, but it is out by at least a couple of orders of magnitude.

Here is a very old analysis of the process creation overhead (I can't find anything more modern after a bit of googling). By old, I'll point out that they call windows NT, and do their experiments on a P200-MMX. Even then, process creation was about 100th of a second. Remember that processors are roughly 20-50x faster depending on how much architectural improvements effect a particular benchmark. The work in spawning a process is roughly constant, although windows may be doing it more efficiently now. I'd guess an upper-bound of 0.2ms on a modern machine.

Re:Slow to start a process!?

[DavidpFitz]

well I do open 75 tabs at once for my morning webcomics though..."Open All in Tabs" has changed my life.

And you haven't been fired yet? Or, if you're self employed have you not fired yourself yet?

Re:Slow to start a process!?

[rrohbeck]

They [processes] 're slow to start up

It's hilarious anyone would think that. We're talking about a web browser, not a web server. Even on platforms where process creation is "slow", it's still going to be instantaneous from a single human's point of view. It's not like the user is opening 100 tabs per second.

Check out Linky.

Re:Slow to start a process!?

[Jenos]

meh I just wake up early enough before work, doesn't take that long to read comics...now reading slashdot wastes loads of time that i justify as tech news and research.

Re:Slow to start a process!?

[Trogre]

"Everyone that has pr0n less nasty than mine is a prude. Everyone that has nastier pr0n than me is a freak." -- Optic7

And what of those of us who don't fit either of those categories? (I'll leave it to you to work out the two possibile scenarios that could bring this about).

Re:Slow to start a process!?

[Jeremi]

It's not like the user is opening 100 tabs per second.

One (possible) exception to the above rule would be if the user is restoring a saved session. e.g. with 100 tabs open, you quit your web browser, and the next time you run the web browser it restores itself to the state it was in when you quit. In that case, 100 tabs would be opened more-or-less simultaneously, and any delays would become quite noticeable.

Re:Slow to start a process!?

[Trogre]

The studies I've looked at when studying Human Computer Interaction point to 200ms as the magic deadline for conveying the illusion of the user directly interacting with the interface. If creating a process is a whopping tenth of a second then we've just used half our available time on just spawning the process.

Re:Slow to start a process!?

[adolf]

IIRC, whence last I checked, Apache was smaller than Firefox. (Feel free to interchange "apache" or "firefox" with probably bloody any other respective programs.)

FYI, FWIW, HTH, etc. But it seems to me that web servers have been forking new processes forever.

*shrug*

Um, duh

[coryking]

Every bandwagoner, technical lightweight is now stomping their feet that Firefox needs to get on this yesterday

Of course they want it yesterday... that is why they aren't as smart as you and I. They think you can go back in time.

Smart people like those reading this comment want it *today* or perhaps tomorrow morning. The honor roll students understand that today or even tomorrow might not be possible and instead are willing to wait a few days. The Mensa crowd and those working on Duke Nukem Forever or Perl6 are willing to wait until the code is the most architecturally perfect code ever written.

My point, for those reading still in the "I want it yesterday" crowd, is that you are asking for the impossible. Please be productive and demand the Firefox developers complete all code related to using a process per tab by the end of the day. Understand that until such time as those in the Duke Nukem Forever/Perl6/Mensa crowd invent the time machine, demands for "I want it yesterday" are simply unrealistic.

Re:victory of tabbed browsing - not defeat of thre

[ceoyoyo]

Your girlfriend is a geek who uses IE7 on Vista? Are you SURE?

And yes, a properly written multithreaded browser can prevent one tab from crashing another. The only way one tab could bring down the others would be if it spewed crap in the shared memory space. If you're letting web pages overwrite whatever memory they want then you've got big problems.

Re:QNX and Microkernels have been doing this forev

[Anonymous Coward]

Microkernels have been doing this forever

Wow. Does this mean what I think it means? Google/HURD!

Stallman, Schmidt and Ballmer throw off their remaining differences to develop a Free software Uber-browser-OS. Features include:

• makes Vista look speedy;
• seperate processes for everything, even right-click menus;
• improved EMacs, that requires 10GB of RAM;
• everything Web based, with all the reliability that entails;
• everything Web based, with all the speed of rendering and JavaScript execution that entails;
• quote of the day, with nothing but anti-Apple propaganda;
• all your software are belong to Microsoft;
• all your content you submit, post or display are belong to Google;
• a free Stallmanator doll with every purchase;
• aaaannnnd Reversii (except in Nebraska!)

Erlang Browser

[bjourne]

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:Erlang Browser

[FishWithAHammer]

It has nothing to do with Erlang and everything to do with basic design principles. Erlang did not invent what it preaches.

Re:Erlang Browser

[Shin-LaC]

Should you really be so proud of that? You're basically telling us that, while nobody has written a serious Erlang browser so far, Google is reaping the same benefits using plain old C++. That's not exactly going to encourage people to spend time learning Erlang.

Re:Erlang Browser

[bjourne]

Erlang is merely an implementation that makes realizing those basic design principles simple because processes have virtually zero overhead so you get fault isolation and recoverability for free. In other environments implementing the same "basic design principles" is complicated and carries a lot of overhead. Which is why most browsers aren't built around the multi-process model.

Re:Erlang Browser

[FooBarWidget]

Erlang processes are not OS processes. If one Erlang process enters an infinite loop, can you kill it without affecting all the others?

Erlang is great for some things but horrible for other things that "normal" languages are good at. Have you tried writing a function which counts the number of occurrences of a character in a string? Compare the Erlang implementation with the, say, Python, Ruby or Java implementation.

Requirements/Trade-offs

[bill_mcgonigle]

There are at least three problems here.

One is efficiency. Nobody will argue that a properly implemented multi-threaded software project is going to be less efficient than a new process per job. If you're writing a server to handle 100,000 connections simultaneously you probably want to use threads.

One is necessity. If you're only going to have at most a couple hundred threads you don't need to think in terms of 100,000 processes - orders of magnitude change things.

The last is correctness. Most multi-threaded browsers aren't actually implemented correctly. So they grow in resource consumption over time and you have to do horrendous things like kill the main process and start over, which loses at least some state with current implementations.

So theory vs. reality vs. scale. There's no "one true" answer.

Re:Requirements/Trade-offs

[ratboy666]

"Nobody will argue that a properly implemented multi-threaded software project is going to be less efficient than a new process per job. If you're writing a server to handle 100,000 connections simultaneously you probably want to use threads."

Um... no. 100,000 threads need to be able to share each others stack. The whole idea behind the threading model is to permit DIRECT use of data amongst threads. Without this advantage... well, why use threads? 100,000 threads each need a stack, and this stack must be of "reasonable" size -- so, allocate 1M per stack. The stacks then take 10GB of memory... This is one of the main drivers to go to 64 bit mode in servers.

Or, you have to go to a "lighweight threading" model... (Something more on the order of co-routines)

Your other two points I agree with.

Re:Requirements/Trade-offs

[tzot]

If you're writing a server to handle 100,000 connections simultaneously you probably want to use threads.

A single process (single-threaded or multi-threaded) would have OS limits on the open file/socket descriptors much lower than 100000.

Typically you would spawn several processes, and then do a

man 2 select

Re:Requirements/Trade-offs

[Znork]

If you're writing a server to handle 100,000 connections simultaneously you probably want to use threads.

If you're after efficiency you might want to use non-blocking socket IO and avoid both thread or process overhead (or some hybrid model, depending on application and CPU demand).

Re:Requirements/Trade-offs

[bill_mcgonigle]

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:Requirements/Trade-offs

[Sancho]

Without this advantage... well, why use threads?

It depends upon your platform, and upon whether thread creation or process creation is faster. In Microsoft-world, threads are basically free while processes take quite a bit of processing power. In current versions of Linux, processes are basically free, and you can decide which to use (threads or processes) based upon the memory concerns you mention.

Re:Requirements/Trade-offs

[Goaway]

"Reasonable" stack size used to be a handful of kilobytes not too long ago. If you're just programming reasonably you will never, ever need even 1% of a one-megabyte stack.

Which means that even if you did allocate one megabyte for each stack, that memory would never actually be used. You'd still run into the 32-bit limit for the virtual memory space, though.

Of course, you can just allocate less stack space.

Also, coroutines need their own stacks just as much as threads do.

Re:Requirements/Trade-offs

[FooBarWidget]

"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:Requirements/Trade-offs

[ozphx]

Hence you would use a work queue and a pool of threads. Not 100,000 threads.

Re:Requirements/Trade-offs

[ozphx]

You'd probably go for IOCP on Windows.

Re:Requirements/Trade-offs

[Anonymous Coward]

You are correct, but using processes would be even worse.

Re:Requirements/Trade-offs

[pAnkRat]

So theory vs. reality vs. scale. There's no "one true" answer.

Damn! I read all replies until down here,
and now you tell my there is no real answer?

I'm going back to DIGG

Huibert

Re:Requirements/Trade-offs

[tzot]

A ha! Erlang threads. There's a difference to OS threads.

Re:Requirements/Trade-offs

[bill_mcgonigle]

A ha! Erlang threads [wikipedia.org]. There's a difference to OS threads.

Ah, thanks, good to know.

Another Benefit: Killing Bad Pages

[ink]

There's another benefit to separating pages into processes. You can use standard OS tools (top, ps, Task Manager, System Monitor) to find processes that are eating up cycles and kill them. If I have 30 tabs open in Firefox, and one of them has some wonky JavaScript/Flash/Java that is munching the CPU, I have to kill the entire browser and start from scratch. With separate processes, I can shut down the specific offender and continue on (assuming it isn't the browser itself). I find this to be the most attractive feature of spreading pages into processes. It allows the OS to control *gasp* applications!

Hum?

[marcosdumay]

Everything is exposed to the OS, not just IPC.

Re:Hum?

[Urban Garlic]

Clumsy wording, sorry. I meant potentially exposed to other users *through* the OS. Other users can find your file or named pipe and DOS your process by deleting it, if you're not careful with permissions etc., but such an attack is much harder against intra-process, inter-thread shared memory.
   

It's different this time around...

[Temujin_12]

Before, when people were arguing between threads vs. processes, most of the arguments assumed ONLY ONE CPU. Forgive me if I'm wrong on this, but my understanding is that one of the biggest reasons modern day programs (programs, not OSs) under-utilize modern multi-core CPUs is that all threads of a process remain on the same CPU as their parent process.

So by designing an application to spawn new processes instead of threads, it un-handcuffs the multi-core CPU and allows it to distribute the work between all of its cores. Isn't this one of the reasons web servers and technologies (apache/tomcat/mod_proxy) spawn listening processes rather than just threads?

Yes, yes, more processes means more overhead, but given the cheapness of RAM, that has to be weighed against the benefits of being able to now access more CPU cores (in which case IE8 and Chrome seem to have chosen to go with the process model).

Re:It's different this time around...

[ShadowRangerRIT]

Wrong. If a process has affinity fixed to a single core, then its threads will be similarly constrained. But threads on an unconstrained process will happily move between cores; that's why you can get really aggravating race conditions on multi-proc machines that don't appear for the same multi-threaded program on a single core machine.

Also, Apache and the like allow the option of threads vs. processes. Traditionally, Windows installs use thread and *nix installs use processes because Windows is optimized for threads and *nix for processes, though it only matters if the server is under load.

quite ironic

[speedtux]

UNIX didn't have threads for many years because its developers thought that processes were a better choice. Then, a whole bunch of people coming from other systems pushed for threads to be added to UNIX, and they did. Now, 30 years later, people are moving back to the processes-are-better view that UNIX originally was pushing.

Microsoft and Apple have moved to X11-like window systems, Microsoft and Google are moving from threads to processes, ... Maybe it's time to switch to V7 (or Plan 9)? :-)

Re:quite ironic

[FishWithAHammer]

...whaaaaaaaat? Microsoft and Apple have moved *away* from X11 window systems. Because they completely fucking suck for desktop use. To get any reasonable desktop performance out of X, you have to replace about half of the server infrastructure (and anyone who thinks the way X.org is designed is *good* should please stop using computers).

People are not moving back to the processes-are-better view, either. In *this* case, processes have some benefits because they provide a greater amount of firewalling in case of crashes, because stability is the primary concern of a web browser these days (we've achieved good-enough performance). Threads are still better for the majority of computing tasks, if only due to shared address space (because IPC sucks to write and debug).

Get off the crack pipe.

Re:quite ironic

[speedtux]

...whaaaaaaaat? Microsoft and Apple have moved *away* from X11 window systems.

Bullshit. Microsoft and Apple never used X11 or anything like it. They used to have hokey direct-to-memory graphics libraries. Now, both of them have moved to a client-sever architecture, with a display server in user space, just like X11.

To get any reasonable desktop performance out of X, you have to replace about half of the server

X11 is actually more efficient than either the Windows or the Mac display servers.

Threads are still better for the majority of computing tasks,

The majority of computing tasks use neither threads nor multiple processes.

if only due to shared address space (because IPC sucks to write and debug).

You can have shared address space with multiple processes.

Get off the crack pipe.

Stop mindlessly repeating Microsoft and Apple marketing babble.

Re:quite ironic

[dbIII]

Microsoft and Apple have moved *away* from X11 window systems

No. Microsoft never made it that far and Apple have recently added X11 to their system. There are actually some quite decent implementaions of X11 for MS Windows by the way.

As for the other comments you'll need to be a bit more specific than "sucks" and I suspect from the tone of the post that you consider "server infrastructure" to be things like badly written graphical file browsers or badly written window managers and not X itself. When I get decent desktop performance on a 85MHz CPU with fairly ordinary graphics hardware and a ten year old implementation of X it is very clear that you can't blame X for poor performance on multi-cpu 2GHz machines.

I suggest talking more about reality instead of hysterical drug references, we're not all young students here so it makes you look more of an idiot to this audience than you may expect.

Re:quite ironic

[RightSaidFred99]

You can have shared address space with multiple processes.

Yeah, that always works so seamlessly and easily, too. The fact is that for most tasks which require multiple paths of execution, threads are are still better for the majority of [these] computing tasks, as the grandparent mentions.

This isn't a sea shift, it's just an instance of process isolation being more beneficial in this case than the better efficiency of threaded applications.

Re:quite ironic

[the_B0fh]

And debugging threads is easy? Oh boy, talk about a crack pipe.

Re:quite ironic

[FishWithAHammer]

Apple *had* an X server implementation when they started futzing with NeXT. They *fled* from using it as the core of their desktop, and for good reason.

And no, douchebag, I don't consider "server infrastructure" to be file browsers or window managers. Trying to write a performant graphics driver for X.org (which is the only X server that really matters, in a desktop context; Xming for Windows, as you alluded to, can't do most of what a modern desktop should be able to, though it's useful for a few tasks) requires you to rip out the lower third of the fucking server and wedge in custom code for it. Linux Hater Blog has an excellent explanation, for the people who don't know what they're talking about (that'd be you, champ): http://linuxhaters.blogspot.com/2008/06/nitty-gritty-shit-on-open-source.html

Re:quite ironic

[ozphx]

Mod it Flamebait if you like (its actually a +1 Flamebait with my config).

Fact is the only good Xserver implementation I've used is NoMachine - which runs an Xserver proxy on the server end which it translates into its own actually efficient protocol to send to the (client/xserver). Then it works fine, but not because of the X implementation.

Re:quite ironic

[dbIII]

Xming for Windows, as you alluded to

No I didn't - I have people using three others on MS Windows (Exceed, PC-Xware, Xwin32) but don't use Xming due to some bug displaying really old motif programs I'm stuck with. Xming is a one man effort so give him a break. Fifth on the list for MS Windows is cygwin which is a bit too user unfriendly at the moment. There are a few others but I'm not familiar with them.

The other thing you were not aware of is that at least the last three releases of Apple's OS X have X11 on the install disks. The most recent release has a similar tool to the X windows style desktop switcher for the standard display manager - to make it behave locally at least as if it had a decent X11 window manager, and then if you run real X11 applications on that they are seamlessly handled by Apple's native display manager.

I'm curious - what is it that a "modern" desktop should do that X11 can't? For me remote window access is the killer app but for somebody looking at it in terms of a single user, non-networked computer what is it that you think it needs that it couldn't already do ten years ago on accelerated graphics hardware? Don't say "3D games" without looking at a WoW forum, please find something it can't do instead of making somehting up.

By the way - I really do not see the relevance of the link to some guy complaining that everyone should have drivers as good as Nvidia's even if I agree with some of it - the hyperbole in the middle of it about having to replace a big chunk of X just to get it to work is dramatic, funny but diverges somewhat greatly from reality. You need to read a bit more widely and get things from more than one source if you want to adequately detect bullshit - perhaps you'll be better at it by the time you graduate.

Re:quite ironic

[Anonymous Coward]

Well, they are not mutually exclusive. Processes are good and threads are good. One problem with UNIX threads was/is because of the POSIX definition of threads. Nowadays Linux have a good thread implementation though.

Re:quite ironic

[TechnicalThug]

"Maybe it's time to switch to Smalltalk"

There, fixed that for you. (Considering most of the (sh)IT world has blatantly stolen from St...)

Re:quite ironic

[Anonymous Coward]

Maybe it's time to switch to microkernels :)

Re:quite ironic

[speedtux]

The fuck wha? Have you actually used X11 remotely vs RDP?

You are really confused.

X11 is designed for local and LAN use. It is very good for that purpose, better than Windows' display server or Macintosh Quartz: it gives very fast local performance and works well over high speed LANs. It was not targeted at WAN or low-bandwidth use. Trying to use Windows display sever or Quartz over a network is so hopeless that it's simply been disabled.

RDP is a completely separate protocol, designed for low bandwidth. The X11 equivalents are LBX, VNC, NoMachine, and a bunch of others. They work very well.

Re:quite ironic

[speedtux]

Fact is the only good Xserver implementation I've used is NoMachine - which runs an Xserver proxy on the server end which it translates into its own actually efficient protocol to send to the (client/xserver). Then it works fine, but not because of the X implementation.

Sorry, you don't know what you're talking about.

NoMachine is the equivalent of RDP: it's a separate protocol specifically designed for low bandwidth connections (there are several others, including LBX and DXPC). Performance of those low bandwidth protocols has nothing to do with server performance. Those protocols spend a lot of CPU and memory to reduce latency and bandwidth. They are not used for local display.

The X11 protocol is designed for high bandwidth connection, such as local IPC and high speed LAN connections. The equivalent of that is the Windows display server internal IPC protocol and the Quartz local IPC protocol; Microsoft and Apple simply have chosen not even to expose those protocols. If they had, they would be worse than X11 over a LAN.

Re:quite ironic

[BitCrazed]

"Microsoft have moved to X11-like window systems"
Erm, no! Windows UI is nothing like X11. Nothing at all. Nada. Zip.

And, no, the Windows world is not giving up threads for processes.

The important thing to remember with Windows is that the kernel schedules threads, not processes. Processes define a collection of threads all of which have access to the same virtual memory space and can thus share data easily and quickly (no cross-process marshalling required).

Processes, therefore, are inherently more costly to create and destroy than threads (have to do all the CPU & MMU config, etc) and so should be used sparingly.

The downside here is that if one thread (running, for example, the code in one web page) crashes, it's likely that the process will terminate and take down all the other threads in the process.

The way to insulate yourself from this? Parition your apps to run different "logical threads" in separate processes - this way, if one thread/process dies, it won't affect any other processes. Clever partitioning (i.e. running all web pages with no or carefully verfied JScript in one process) can help mitigate the cost of process creation.

Re:quite ironic

[BitCrazed]

And debugging threads is easy

Debugging most threaded/multi-process code is hard. It's not threading per-se that makes this hard - it's the nature of the beast - concurrent programming is hard.

There are many efforts across the industry that are working on making it easier to write and debug concurrent code - an incredibly important activity considering that most new PC's will have at least 8 cores by the end of next year!

Its not always one process per tab

[pfafrich]

The comic is a lie. The allocation of processes is quite complecated chromes-process-model. With a standard install you can quite easily create multiple tabs per process. Basically on a website site right click on a link to a page in the same website and select open in new tab. The new tab is then allocated to the same process. Once you have such a tab you can navigate to elsewhere on the web so you can easily end up with a situation where two different website in two different tabs share the same process.

Re:Its not always one process per tab

[mini me]

It says that when you navigate elsewhere (e.g. mail.google.com to hotmail.com), the underlying process can change.

So what's the typical cause of a browser crashing?

[Anonymous Coward]

Just what is exactly causing browsers to crash anyways?

Javascript? Wait, that's an interpreted language. If it's causing your browser to crash, then isn't there a problem with your interpreter?

HTML? Wait, if your browser is crashing on HTML, isn't the rendering engine buggy?

If anything is causing a browser to crash, I would suspect that it must be a plugin... And if that's the case, would it not make more sense to make the plugin run in a separate process instead?

Crash tolerance?

[ElboRuum]

Crashing is a sign that you ought fix your code, not stuff it in its own process. No web page should ever crash a browser in the same way no driver should ever crash an OS.

Clue: the problem isn't with primarily with the person who wrote the web page or the driver, although they should really go back and fix their shit too. The problem is with the browser or the OS.

If you need more than a thread to put up a web page and claim its all about the stability, accept the fact that you just plain suck and eff your crash tolerance.

Re:Crash tolerance?

[ShadowRangerRIT]

Crashing is a sign that you ought fix your code, not stuff it in its own process. No web page should ever crash a browser in the same way no driver should ever crash an OS.

Good point, but bad analogy. A lot of drivers need permission to crash the OS by definition. You can try to limit the amount of kernel mode elements, but at the end of the day the driver needs to be able to directly communicate with hardware.

Re:Crash tolerance?

[FishWithAHammer]

If you can't fix every bug--and you can't, so don't troll and say you can--graceful recovery is the next best thing. We live in the real world, not the computer scientist's world of "code can be perfect."

Re:Crash tolerance?

[rkanodia]

Good point. It's much better to be full of hubris and act as though you will never make mistakes than to take precautions that reduce the harm a mistake could cause.

Re:Crash tolerance?

[smellotron]

Actually, the computer scientist's world is more like, "This program is provably impossible to verify for correctness." At least, unless you severely constrain the problem, which is the alternate theoretical approach (see qmail for an example).

Re:Crash tolerance?

[FishWithAHammer]

I know. I was being a tongue-in-cheek asshole. :) An unpleasantly large number of computer scientists I know think you really can bash out every bug, though. The real world is not high on their list of priorities.

I used to run my entire desktop on a cluster

[Colin Smith]

Execute everything under a qsub command.

None of the processes were running on the same machines, don't know and don't care where they were. It's actually a more efficient way of running applications. All the firefox processes run on a few firefox servers, all of the OpenOffice processes run on an a few OpenOffce servers. Load balanced of course.

Running multiple instances of the same application on the same machine allows the most efficient use of RAM, CPU caches and of the CPU processing power. The libraries are only loaded once, it's only user data which takes up memory and that is a tiny fraction of the memory consumption. Plus, it screams. How often have you seen Open Office start in half a second?

 

Re:I used to run my entire desktop on a cluster

[Anonymous Coward]

Beside the point I don't want to send my usage information to some central server, and I am not sure that safing a few seconds startup time is worth the hassle,

how does a process for each tab help this issue?

Re:Hilarious...

[Firehed]

Everything is obvious in hindsight. We're really just bashing the fact that MS beat Mozilla to the punch on this one, where the opposite is almost always the case.

Slow?

[dadragon]

Maybe my computer is fast (X2 4600+, 2GB Ram), but Chrome doesn't seem slow to me. I know Microsoft made a lot of under-the-hood improvements to Vista, is process creation overhead one of them? I hear a lot of people saying it's incredibly slow to open a new tab. Is everyone else running XP?

Re:Slow?

[Anonymous Coward]

Maybe my computer is fast (X2 4600+, 2GB Ram)

Uh... Yeah, your computer is fast. That's a pretty damn beefy processor there. Chrome would probably have to be playing Oblivion in the background for you to notice any slowdown. Try again on, say, a 2 GHz Celeron with 1 GB RAM, and maybe you'll see what people are complaining about.

Re:Slow?

[Shados]

Processes are slow, but a stupid browser with a process per tab is never going to be bottlenecked by the insignificant overhead of a process.

You start to feel process bottlenecks if you have a CGI-based web app (let say, a PHP or a PERL app) which runs each request in its own process (which is more or less an obsolete way of doing it). Now that hurts when you're creating hundreds of threads per minutes on a machine thats already taxed by the processing of these requests.

Tin-foil hats

[Balial]

Yup... same here on a previous thread. For those too lazy to click the link:

What do you want from future browsers?

Privilege separation... plain and simple. That's it. The fact that a JPEG, WMF, TIFF, PNG, Flash, Javascript or whatever bug can take down the whole browser or exploit some bug to execute arbitrary code with your user's privilege level is a sick joke from ever browser author.

Re:Firefox Left In The Dust By Chrome...and IE, LO

[FunkyELF]

It did sound a little Flamebaitish but seriously, Firefox is horrible on Linux. It is slow and little javascript / css menu dropdowns appear behind flash objects and I can't click them. I wind up firing up Windows in VirtualBox just to be able to click on a link. Maybe it is adobe's fault...I dunno.

Designs might be interesting, though results count

[Device666]

In older days working with processes was more easy, later threads came, and then truning to processes agin. Every model works best under certain conditions, conditions change so do designs (even when it doesn't sound too much of an innovation). In the end the results count.

Design models are nice, but getting designs implemented right so they live up needed target result is something else. Google has done a nice job and so does Firefox. Microsoft should learn from this.

As long as Internet Explorer is not performing well there's so much room for others to gain marketshare. For the user to have something to choose from is a good thing.

Re:Firefox Left In The Dust By Chrome...and IE, LO

[Now.Imperfect]

Flamebait? I think not. FF is an awesome browser that I use as my default. But it does look to be lagging!

Testament indeed

[overshoot]

It is an amazing testament to Google that they have achieved the multi-process, single UI model (I just don't know how they did the portability part).

It's not altogether clear that they have ...

I don't get it

[Anonymous Coward]

Ok, for example how is this different from the child processes a web server spawns? I mean, it's not something new and unheard of.. Next thing they'll say you can run them as different users for increased security.. amazing..

Thread's == FAIL

[Anonymous Coward]

seriously ever try and debug a threading issue? Keep it separate processes please. Also Erlang concurrency is a good approach I think.

Re:So what's the typical cause of a browser crashi

[FishWithAHammer]

There are edge cases where HTML will crash IE (or used to), and I remember some cases that would kill Gecko.

JavaScript is an extremely gnarly language to actually implement (most prototype-based languages are), and it's very difficult to stomp on all the bugs. There are also cases where an infinite loop in the JavaScript can wedge the browser, which this alleviates.

Plugins are a major issue, and that's almost certainly the next thing to be put in its own process.

Keep in mind that yeah, there are bugs in browsers, and they should be stomped on--but you can't get them all, and graceful recovery is still great to have.

A surprise? Really?

[Anonymous Coward]

I don't think that word means what you think it means. Google ADVERTISED that Chrome used a separate process for each tab, that was the main selling point.

Re:A surprise? Really?

[Anonymous Coward]

That advertising turned out to be a lie. Chrome has a max of 20 processes, so if you make more than 20 tabs, you'll end up with multiple tabs sharing a process. Also, tabs hosting web pages within the same domain share the same process. But of course, Google's never been above lying ("we're not evil" is the biggest of their lies).

Re:Designs might be interesting, though results co

[FishWithAHammer]

Firefox has done an absolute shit job. Right now, Firefox is, full-stop, the worst browser out there.

For that matter, IE8 already does what Chrome does. The browsers that don't are Konqueror, Firefox, Safari, and Opera (plus the assorted little browsers not worthy of mention. Get a clue.

IE8 will be performing well, and Firefox is going to have their balls in a vise, crushed by Chrome and IE8.

Ruby and Rails beat them to it

[Peter Cooper]

Okay, I know this isn't a great precedent, but considering the ribbing Ruby and Rails have gotten for pushing the multiple process model (mostly because Ruby doesn't do OS-level threads, only "green" threads) it's intriguing that it's now becoming en vogue while Ruby is pushing to implement system-level threads in anger!

Re:Ruby and Rails beat them to it

[smellotron]

Your statement reminds me of a legless man bragging to someone who chooses to sit down.

Re:victory of tabbed browsing - not defeat of thre

[caerwyn]

Ahh... that's the entire point. Multiprocess models are generally an acknowledgement of the fact that there are problems, and a way to mitigate their effect.

If you're running 3rd-party code inside your memory space in a thread (read: plugins) there is nothing you can do to prevent that code from trashing your process. The only solution is to isolate the resources they have access to by sticking them into a separate process.

In addition, it is *very* easy for bugs to make cause errors in shared data structures that end up corrupting the memory space for all threads. This is also true if you're using shared memory across processes, for that matter- if one process using the shared memory goes down, the entire shared memory must be considered suspect and trashed unless you've got some protected way of verifying/correcting it.

IPC over pipes or the like, with strict and correct validation of the messages passed there, is really the only way to correctly sandbox separate processes that want to work together yet be immune from non-local faults. Even then, if the processes have any sort of dependencies (children on a manager process, for instance) there may not be anything you can do to avoid a global failure if the dependency's target fails.

Response from the Matrix on Forkin Hell

[Anonymous Coward]

> > forkin hell!
> And here I was hoping I'd see a Spoonerism somewhere.

There is no spoon

Processes less frustrating then threads.

[wozzinator]

The whole deal with having a different process for each tab means that when a tab would normally lock up, it would take out the whole browser, whereas with seperate processes, the memory allocated to the processes are seperated which allows only one tab to crash and not the whole browser itself. Threads on the other hand are all apart of the same process which means if one tab contained in a thread crashes, the whole browser crashes. Granted I love threads, but in terms of that one pop-up crashing the 8 tabs I had open in firefox, good riddens.

Re:victory of tabbed browsing - not defeat of thre

[Anonymous Coward]

Look at the history of Windows versions, so many of the changes from the early days through Vista are about defending the OS from third party software. (Both from crashing when running crapware, and from spewing all over the OS system files during installation of crapware.)

Third party software is often pure crap that can take down everything else.

The point is, you can't just say "write browsers that don't crash". Because you're going to use sites with crappy code and plugins or whatever that *are* going to crash no matter how good the browser is. (But ok sure, fix the browser bugs too please.)

Re:Hilarious...

[Schnoogs]

HHAHAHHAHA!!

I was modded flamebait for making a legitimate observation about others who were essentially trolling with their unchecked cynicism.

I love this site...I really do. The few times I've been given negative mod points is whenever I call out others for being biased, cynical, etc.

Hilarious and pathetic at the same time.

Could someone give the gory details

[melted]

Could someone give the gory details on how this all is accomplished? In particular, whether all processes access (and draw in) the same graphical context somehow, or they're just a bunch of z-ordered overlapping windows that move together when dragged?

Re:Could someone give the gory details

[Shin-LaC]

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.

Re:Could someone give the gory details

[Johnno74]

I was wondering exactly the same thing, thanks

google comic strip

[Danzigism]

I found Google's comic strip on process threading incredibly useful for explaining how all this stuff works.. I highly recommend reading it. check it out here.

Re:So what's the typical cause of a browser crashi

[zuperduperman]

> Plugins are a major issue, and that's almost certainly the next thing to be put in its own process.

Actually, if you read the comic, in Chrome (apparently) plugins already run in separate processes to the pages they live in. This is one of the most interesting aspects of it.

Processes good, BSOD bad...

[gtoal]

Process separation is a good idea, but the practice is somewhat different - my wife installed Chrome, and whenever it crashes, which is quite often, it BSOD's her computer, causing a reboot!

Re:Processes good, BSOD bad...

[Danzigism]

you need to run a Crash Dump Analysis using MS's debugging tools.. I can almost bet it's a BHO or something like your AV software causing it to crash.. at least the analysis will pin-point what .sys or .dll is causing the bluescreen.. you can find the debugging tools here. I mention this because I haven't had Chrome crash on me once. but before blaming Chrome, I would look at what is really causing the problem. i truly believe it could be something entirely different.

I offer a truely novel idea

[Anonymous Coward]

Oh god this is truely pathetic. Please save us all from obvious conceptual lessons about process isolation and complexity management.

Major browsers represent significant world class endeavours. If google is not prepared to be serious about it and invest the proper resources then I wish they would just close up their little project and get back to useful work like eliminating all of the link farm spam nonsense (largly subsidised by google adwords) that seem to dominate many of my google search results.

Heres an extremely unwise and unpopular idea... Hows about writing browsers that don't crash in the first place?

In todays "hostile" environment if your writing code that can crash you are most likely also writing code that can be explioted and ruin a whole lot of peoples days as their machines get 0wned and turned into bot-net-zombies.

I tried IEs last beta and it was completely unusable - right clicking a link and opening in new window would start a new process that was so new it didn't inherit cookie state or anything from the parent window. From what I hear chrome suffers similiar problems. Get it right or don't release it even as public beta... The bar should not be lowered to make novel newcommers feel wanted.

Re:victory of tabbed browsing - not defeat of thre

[ceoyoyo]

You can isolate threads from each other by not using shared memory as well. The only advantage to processes over threads is that the OS (MOST OSes) won't let one process write outside it's own memory space.

So processes make sense for certain things. BUT, in a web browser you're interpreting potentially malicious code from the open Internet. If your interpreter, be it the built in HTML parser, JS engine, or a plugin of some kind, has a penchant for overwriting memory it shouldn't, then the crash should be an excellent indication that you should be running that plugin, or that the built in interpreters have some serious security vulnerabilities and need some work.

I agree that isolating tabs in separate processes will potentially let your browser keep limping along. I disagree that this is a good thing.

I already run Firefox in separate processes

[Skapare]

I have a script that fakes a new home directory, and that keeps each new instance of Firefox from passing the URL over to the older process and exiting. This script is run when I launch a new browser, whether with a URL or not. It builds the fake home directory from a template (a tarball), makes the HOME environment variable point at it, and after a few other manipulations, fires up Firefox itself.

In theory it uses more memory. In reality I quit browsers I'm done with and they clean up well when the process exits. So the overall memory usage is actually less. And when one crashes or goes into a loop and needs to be killed (as happened last night on the Comcast web site), I only lose that process. I do not lose all the other browser instances I still may have sitting around and running (typically 5 to 8 started at any given time ... one of which is exclusively for Slashdot). It has worked rather well, so far.

Re:I already run Firefox in separate processes

[Anonymous Coward]

firefox -no-remote -profile /path/to/empty/directory/or/old/profile http://example.com/

How do you deal with bookmarking? Or is there a single special instance you use? Or just use sites like del.icio.us?

Oblig fashion.

[Ostracus]

...Bell bottoms are back in style.

Re:Oblig fashion.

[sharvari]

hey thats a great news but if you want to know more about fashion and the latest trends then just visit www.fashionmoksh.com...........you will also get information on the happenings of the lakme fashion week and the couture week. http://www.fashionmoksh.com/Happenings/Lakme-Fashion-Week--09.aspx http://www.fashionmoksh.com/Happenings/India-Couture-Week.aspx

Re:victory of tabbed browsing - not defeat of thre

[ceoyoyo]

That's the problem - with the OS you installed the app, you're responsible for it. If you run someone else's app on your machine, all bets are off.

With a web browser there's the expectation that a random web site should not be able to do bad things to my computer. If your browser crashes a lot it's annoying and I know it's unstable. If the crashes are covered up somewhat by using the OS to police separate processes then I'm more likely to blame the web site and not your browser.

Problem is, the fault IS in the browser. If I can write some HTML or javascript that crashes (or exploits) your rendering engine, that's a serious security flaw in the browser. The more obvious and irritating that situation is, the more likely it is to get fixed.

What's with the tags?

[quadelirus]

Just curious: how did this story get a Unix tag before it got a Windows tag? Both Chrome and IE 8 are Windows programs (oops, I almost wrote "apps").

Re:What's with the tags?

[ZigMonty]

Because the concept of having many small processes instead of a few massive ones is one of the core concepts that made unix successful?

Re:What's with the tags?

[quadelirus]

Sure, that's true, but aren't tags for search purposes. I just don't see myself wanting this story coming up when I search for "Unix."

Or maybe I don't understand the purpose of tagging.

Re:What's with the tags?

[ZigMonty]

Nah, you're right, it's an abuse of the stated purpose of tags. Not exactly uncommon though.

What i care are not processes or thread

[chairam]

I use FF3 on XP in a heavy way: 8 windows, 20 tab each one. I also use suspension so it accumulates a lot of trash in its cache because i rarely restart it. I usually see FF grow over one GB. This is not the problem I bought ram for that. The problem is the performances! I tried Chrome and I like it even if it takes more ram than FF. The real point is: give me a way to identify which tabs make my browser hang, and how much mem they use so that I can close them if I need. I don't care if a tab is implemented with a thread o process.

Re:Firefox Left In The Dust By Chrome...and IE, LO

[SanityInAnarchy]

It is slow

Are you sure that's not Flash? Or nspluginwrapper?

and little javascript / css menu dropdowns appear behind flash objects

Known bug. I think Flash finally solves it, but only in recent versions of Flash and Firefox 3, and only on 32-bit.

Maybe it is adobe's fault...

<rant>Everything is Adobe's fault.</rant>

Processes? Threads?

[Aaron Aardwolf]

I have several threads, of undetermined material, now hanging from the sleeping bag in which I sleep on the basement sofa.
Threads? Ya want some? I generally snip 'em with my nail-clippers, and subsequently use 'em as dental floss.
If the damn cats don't swallow them first.

The few processes I am able to understand are-
-Wake up in the morning...
-Take a dump,
-stagger off to the computer,
-and then rant on /. about how "VISTA SUX".
-Before Mom yells "Why don't you get a fukin JOB!"

My whole LIFE is a buncha fukkin thread processes!
If only I coulda been a broad like Sylvia Plath...
.

Browsing porn

[Anonymous Coward]

I don't know how YOU browse porn, but I go to a gallery and ctrl-click every image that looks like it might whet my whistle, sometimes opening up 50 or more tabs, then pulling out my peter and inspecting each and every tab, saving and closing them one by one. How will chrome's process-per-tab model handle this I ask you!!!

Re:Browsing porn

[Anonymous Coward]

Wouldn't it be easier to middle-click? Especially if your other hand is busy.. ;)

Re:Designs might be interesting, though results co

[FishWithAHammer]

Troll? Really? Because I said something against the beloved Firefox?

Re:So what's the typical cause of a browser crashi

[FishWithAHammer]

I hadn't read the comic. Very cool, though. Hopefully IE8 does the same thing (probably IE9, though).

Re:victory of tabbed browsing - not defeat of thre

[caerwyn]

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.

In Soviet Russia...

[Anonymous Coward]

THREAD terminate YOU !

no more crashes that take down all your open tabs.

[Anonymous Coward]

I think this makes the browser's more robust. There's nothing more annoying than having 10 tabs open and IE crashing and taking them all down.

Threads + firefox = trouble

[Viol8]

"I can count on one hand the number of times I've had a problem with Firefox that would have been solved by it being in its own process."

Really? Well I would need an abacus the size of france to count the number of times it would have solved a problem for me. Firefox + flash are a well known crash/lockup combination on linux and of course since the browser is threaded ALL instances lock up.

Whats ugly about IPC?

[Viol8]

Shared memory is so simple a child could use it and pipes lend themselves quite nicely to multiplexing.

Actually, the problem is in the hardware

[master_p]

CPUs are not designed to provide component isolation within a process. You either share everything or nothing. That's a VERY BIG PROBLEM, that not only affects browsers, but also kernel design. The battle between micro-kernels and monolithic kernels exists simply because there is no in-process component isolation enforced at hardware level.

In the context of a previous Slashdot discussion on Microkernels, I emailed Andy Tanenbaum and asked him what he thinks of hardware component isolation inside processes. He welcomed the idea, but he said it is going to be a tough sell to CPU manufacturers.

Personally, I don't think that much change is required in CPUs. Actually, what is only needed is two more tables: a) a table like the page table, that defines component boundaries within a process, b) a component function entry table. Accessing something outside of the boundaries would cause a hardware exception. Accessing a function of another component should only be allowed if the target address is contained in the function entry table. Both tables could be implemented as assosiative caches, with very little CPU die dedicated to them.

Not happy about Chrome, sticking with FF3

[Anonymous Coward]

Wow, I uninstalled Chrome after I found this out. Just loading chrome eats up almost 100MB ram. Ridiculous. I mean, I have 5gb of ram, but no way am I loading something on my system that eats that much ram up. Not to mention the processes involved. I think Google needs to revamp this and take the bloat out of it

Addendum...

[Anonymous Coward]

This doesn't really contradict anything you said (since you were talking about the actual underlying implementation), but...

If you're using a decent language like Erlang using threaded I/O with 100,000 connection is(*) not a problem. That's because Erlang is free to do non-blocking I/O even if it looks like normal threaded I/O in your program.

(*) Should not be. I'll freely admit I don't know what Erlang actually does, but if it does anything other than non-blocking/async I/O behind the scenes I'd be very surprised.

Process and thread differences in Win32?

[BcNexus]

I've searched before but haven't found a clear answer. What's a process and what's a thread in Win32, and what are the differences?

Re:Process and thread differences in Win32?

[AlgorithMan]

different threads of the same process share the same memory (so they can access the same data, which causes the "mutual exclusion problem" - see http://en.wikipedia.org/wiki/Semaphore_(programming) ), where different processes have to exchange informations through pipes, files, sockets, dcop...
sharing informations between threads is faster and easier (although you need to synchronize the access, using semaphores), but different processes (programs) should not be able to access each others memory, for security reasons.

Re:Hilarious...

[dzfoo]

Actually, a lot of us are bashing both MS and Google by criticizing the merits and practicality of process-per-tab/page architecture. Pointing out that it is an old idea just adds to the argument that perhaps it was discarded or obsoleted originally for a reason.

But of course, what's old is new. Plus ca change, plus c'est la meme chose. (damn! can't use unicode in Slashdot??)

        -dZ.

Windows IPC

[Anonymous Coward]

Windows interprocess communication has become easier and easier over the decades. It is so robust that (8 years ago) you could use your clipboard and custom clipboard formats to store IPC data. The clipboard system is so advanced that any process that subscribes to the clipboard event model will be notified when new data arrives. Using named pipes is easy as well. One great feature about Windows is that you can construct your files to be based on sockets, named pipes, and file based data, using the same programmatic interface. It is actually very robust and IPC on Windows is very developer friendly. This is just in my own experience. I know that Windows sucks elsewhere, but I will defend it for IPC.

Re:victory of tabbed browsing - not defeat of thre

[ceoyoyo]

"If the threads *can* write into other memory, then there is the danger that broken code *will* do so."

And that is exactly my point. Any broken code allowing memory writes where it shouldn't is a serious security vulnerability. It is better that that broken code crash the whole browser, because then it will get fixed faster. If it just crashes a few badly written web sites it will be a low priority fix... until someone exploits it.

Re:victory of tabbed browsing - not defeat of thre

[caerwyn]

The problem with this is that there are actually two solutions.

You're arguing that security vulnerabilities should just (potentially, potentially not) cause crashes in the hope that this gets them fixed faster. However, you should be aware that not all such bugs actually cause immediate crashes- some just corrupt state. You're also arguing, effectively, for leaving the vulnerability there until it is fixed.

The other option is to sandbox things so that it doesn't matter if there's a vulnerability- if the process is correctly sandboxed, unless there's an OS bug that would allow privilege escalation, nothing can be exploited.

You're basically saying "let's try to make these problems more obvious so they get fixed faster". A properly written process model is saying "let's acknowledge that such bugs may always exist, and prevent them from harming anything at a higher level".

My take so far...

[^_^x]

Listening to the explanation of Chrome it sounds like it has a lot of good ideas on paper. When I look at it practically, as an Opera user, it does a lot of things differently in order to solve problems I never had in the first place, but overall it still hasn't implemented things I take for granted now.

Processes were only slow under Windows

[Anonymous Coward]

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.'"

          They've NEVER been slow under Linux. Or I think Solaris. Or several other UNIXes. A process is just a thread with it's own address space, so the time difference between them is approximately 0. The aversion to processes, and using threads constantly instead, is a Windows thing, because launching processes used to be like 10x slower (or worse) than threads (I don't know if it still is.)

Re:victory of tabbed browsing - not defeat of thre

[ceoyoyo]

If you have a bug that can write arbitrarily to the process's memory space then it doesn't matter whether that bug is in it's own process, or in a combined process with the rest of the browser. There's no reason why the main browser process should be running with any higher permissions than the tabs. I can see a possible exception for some kinds of plugins. Running a plugin or a flash interpreter in a nice low permissions process might be a good idea. I don't think running the whole tab that way is.

You're attributing something to this "properly written process model" that is unjustified. The tabs need just the same (or higher) privileges than the main browser process. Google themselves haven't said anything about sandboxing. They've only stated that their goal is to prevent one tab from crashing another.

Security Advances Slowdown

[flavious]

Right, now simply create a process for every new page I visit, and hell, even two for my favourite pr0n sites which use flash, because you're too lazy to make your browser multithreaded and bug-free. Heck, there's enough memory for everyone on my PC.

Re:So what's the typical cause of a browser crashi

[flavious]

I need my flash pr0n player in its own process. Everything else may crash but I can go on watching.

Not been on the 'net recently ?

[DrYak]

and plug-ins are created by an idiot

I think that you, sir, either haven't seen what populates the web recently. Or you've been dead.

More seriously :

I can count on one hand the number of times I've had a problem with Firefox that would have been solved by it being in its own process.

I can deduce that, apparently, you don't use Adobe's abominable Flash which is a frequent Firefox crasher (thankfully, I don't have to either), nor Adobe's awful Acrobat which can freeze Firefox for several minutes at startup and even more on close (luckily neither do I) nor have a browser which completely freeze for a couple of minutes once a huge download is finished, while an on-demand scanner analyses the file (sadly, sometimes I have to put up with the world-of-worm which is Windows and adding ClamWin seems to be a necessary evil).
Also, you seem to exclusively run a very small amount of very meticulously selected plug-ins, none of which were written "by an idiot".

Your life on the web is probably a very happy one, bar from the occasional blinking GIF that manage to slip through AdBlock+ (which I think count among the few selected plugins that have the privilege to be allowed to run on your browser).

The sad truth is that your situation, although typical for a /. geek, isn't even remotely representative of the random Joe-6-pack netizen "of teh interwebs".

They have to put up with a world of pain composed of constant crashes and slow downs (admittedly, half of which are caused by all the ad-/spy-/mal-wares running because of the random clicking on unknown mail attachment).
And they would definitely benefit from a multi-process browser. (Also, that browser could finally put at good use the quad-core expensive overkill that the random Joe-6-pack user got conned into buying by the store's vendor)

Also don't neglect a significant advantage of a multi-process system (which was humorously pointed in the launch ad) :
- The user will more easily know who's to blame for any instability issue. Because only *that* process will crash while everything else continue to work.

That may help put an end on all these "FireFox is a bloated crash-prone resource hog" trolls.

Let me scrape up some of that...

[ElboRuum]

BS... Hubris has nothing to do with testing and bulletproofing code. Planning for epic fail with a kluge (and it IS a kluge no matter how you may attempt to spin it) instead of designing a piece of software correctly is just lazybonez.

Show me the logical proof that states...

[ElboRuum]

...that you can't fix every bug.

I'm not disagreeing necessarily with the pragmatic implication, but you don't win points by committing fallacies. "We live in the real world, ergo nothing's perfect" is essentially the simpleton's strawman. The fact of the matter is that code can be crash tolerant, and yes graceful recovery is the next best thing. However the answer is not "If we put this crashy little thing over here in its own process and let it take a crap here so it doesn't wreck everything". Has this addressed the issue causing it to crash? Not at all. In fact the trade-off is clear. Much greater resource utilization.

Maybe you can't fix every bug. But you can fix most. See, built in crash tolerance: reduce the number of bugs causing crashes. Besides IE6 had a similar crash tolerance scheme. Multiple web pages? Multiple browser windows. For some reason, they decided tabbed browsing would be better for some reason. Oh well.