×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

In IE8 and Chrome, Processes Are the New Threads

kdawson posted more than 5 years ago | from the keeping-intel's-margins-healthy dept.

Programming 397

SenFo writes "To many of the people who downloaded Google Chrome last week, it was a surprise to observe that each opened tab runs in a separate process rather than a separate thread. Scott Hanselman, Lead Program Manager at Microsoft, discusses some of the benefits of running in separate processes as opposed to separate threads. A quote: 'Ah! But they're slow! They're slow to start up, and they are slow to communicate between, right? Well, kind of, not really anymore.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

397 comments

Have to watch what I say (5, Funny)

bigtallmofo (695287) | more than 5 years ago | (#24952317)

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 (0)

Anonymous Coward | more than 5 years ago | (#24952531)

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

Re:Have to watch what I say (0)

Anonymous Coward | more than 5 years ago | (#24953351)

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/

Processes (5, Interesting)

Ethanol-fueled (1125189) | more than 5 years ago | (#24952331)

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 [slashdot.org] 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 [slashdot.org] 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 (5, Insightful)

ergo98 (9391) | more than 5 years ago | (#24952453)

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 (2, Insightful)

7 digits (986730) | more than 5 years ago | (#24952741)

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

Um, duh (2, Funny)

coryking (104614) | more than 5 years ago | (#24952869)

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:Processes (1, Interesting)

Anonymous Coward | more than 5 years ago | (#24952947)

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 (4, Insightful)

FishWithAHammer (957772) | more than 5 years ago | (#24953059)

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 (0)

Anonymous Coward | more than 5 years ago | (#24953243)

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 (3, Insightful)

gnud (934243) | more than 5 years ago | (#24953369)

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 (2, Interesting)

TheRealMindChild (743925) | more than 5 years ago | (#24952555)

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 (2, Insightful)

ShadowRangerRIT (1301549) | more than 5 years ago | (#24952913)

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 (1)

TheRealMindChild (743925) | more than 5 years ago | (#24953031)

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 (4, Funny)

piquadratCH (749309) | more than 5 years ago | (#24953065)

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.

I used to run my entire desktop on a cluster (1)

Colin Smith (2679) | more than 5 years ago | (#24953245)

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:Processes (0)

Anonymous Coward | more than 5 years ago | (#24953057)

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

Re:Processes (4, Insightful)

ThePhilips (752041) | more than 5 years ago | (#24952795)

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 (1)

FishWithAHammer (957772) | more than 5 years ago | (#24953081)

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

Tin-foil hats (1)

Balial (39889) | more than 5 years ago | (#24953353)

Yup... same here on a previous thread [slashdot.org]. 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.

So... (5, Insightful)

Anonymous Coward | more than 5 years ago | (#24952367)

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

Re:So... (3, Insightful)

moderatorrater (1095745) | more than 5 years ago | (#24952447)

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... (2, Funny)

InlawBiker (1124825) | more than 5 years ago | (#24952799)

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... (1)

clodney (778910) | more than 5 years ago | (#24952865)

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.

Oblig (5, Funny)

plopez (54068) | more than 5 years ago | (#24952387)

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

Re:Oblig (4, Funny)

Anonymous Coward | more than 5 years ago | (#24952701)

1990 called, they'd like their joke back.

Deja vu (5, Insightful)

overshoot (39700) | more than 5 years ago | (#24952415)

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 (2, Interesting)

LWATCDR (28044) | more than 5 years ago | (#24952617)

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.

Firefox Left In The Dust By Chrome...and IE, LOL! (0, Flamebait)

Rachman (1358849) | more than 5 years ago | (#24952877)

It has got to be the ultimate humiliation for the Firefox developers and hardcore fans to be left in the technological dust by Microsoft's Internet Explorer team.

Given how old and poorly written the Firefox code is it shouldn't surprise anyone that a company like Google who has some of the most brilliant developers in the world working for them came out of nowhere and developed a browser that blows the doors off of old buggy, bloated, and slow Firefox.

But Microsoft too...ouch!

Requirements/Trade-offs (4, Insightful)

bill_mcgonigle (4333) | more than 5 years ago | (#24952979)

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 (1)

ratboy666 (104074) | more than 5 years ago | (#24953311)

"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:Deja vu (5, Interesting)

Anonymous Coward | more than 5 years ago | (#24953089)

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 (1)

Firehed (942385) | more than 5 years ago | (#24953123)

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 (4, Insightful)

FishWithAHammer (957772) | more than 5 years ago | (#24953275)

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 (4, Insightful)

shird (566377) | more than 5 years ago | (#24953279)

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.

Hilarious... (-1, Flamebait)

Schnoogs (1087081) | more than 5 years ago | (#24952421)

...how everyone in this thread has tried to belittle this since separate processes have been around for decades. Well if its so obvious then why is in in 2008 we're finally seeing this in browsers? We're all of you complaining about the absence of this feature every year prior to this since Tabs first debuted?

Re:Hilarious... (2, Informative)

dzfoo (772245) | more than 5 years ago | (#24952709)

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.

Re:Hilarious... (1)

Firehed (942385) | more than 5 years ago | (#24953299)

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.

Hmm, interesting (0)

Anonymous Coward | more than 5 years ago | (#24952433)

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 (1)

flyingrobots (704155) | more than 5 years ago | (#24952459)

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

Re:QNX and Microkernels have been doing this forev (0)

Anonymous Coward | more than 5 years ago | (#24952971)

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!)

Only one benefit discussed: isolation (3, Informative)

michaelepley (239861) | more than 5 years ago | (#24952465)

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 (4, Insightful)

ceoyoyo (59147) | more than 5 years ago | (#24952831)

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?

Another Benefit: Killing Bad Pages (2, Interesting)

ink (4325) | more than 5 years ago | (#24953029)

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!

Re:Only one benefit discussed: isolation (2, Interesting)

FishWithAHammer (957772) | more than 5 years ago | (#24953349)

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

Chrome = slow as hell (3, Interesting)

Xaximus (1361711) | more than 5 years ago | (#24952491)

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 (1)

LWATCDR (28044) | more than 5 years ago | (#24952585)

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

Poor Little Firefox Fanboys (-1, Troll)

Anonymous Coward | more than 5 years ago | (#24952747)

They are so desperately trying to flood the Net with their desperate attempts to stop the flood of people dumping Firefox for Chrome.

Re:Chrome = slow as hell (5, Informative)

B3ryllium (571199) | more than 5 years ago | (#24953045)

"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 (1)

ShadowRangerRIT (1301549) | more than 5 years ago | (#24953291)

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 (2, Insightful)

B3ryllium (571199) | more than 5 years ago | (#24953313)

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

Re:Chrome = slow as hell (0)

Anonymous Coward | more than 5 years ago | (#24953113)

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 (0)

Anonymous Coward | more than 5 years ago | (#24953167)

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.

There's another cost to seperate processes (2, Interesting)

sqlrob (173498) | more than 5 years ago | (#24952521)

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

Cheap and Dirty Crash Isolation... (5, Insightful)

nweaver (113078) | more than 5 years ago | (#24952541)

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... (2, Interesting)

lgw (121541) | more than 5 years ago | (#24952707)

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... (1)

Kalriath (849904) | more than 5 years ago | (#24952867)

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... (1)

Midnight Thunder (17205) | more than 5 years ago | (#24952771)

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... (1)

FishWithAHammer (957772) | more than 5 years ago | (#24953381)

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.

Process creation slow?? (0, Redundant)

Anonymous Coward | more than 5 years ago | (#24952545)

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.

Slow to communicate? (1)

ScubaS (600042) | more than 5 years ago | (#24952549)

I don't understand why it makes a difference. I would be really concerned if a webpage was trying to communicate with another webpage through the tabs. As far as I know, there is no reason for browser processes to communicate between each other.

I doubt that (1)

Just Some Guy (3352) | more than 5 years ago | (#24952563)

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

Re:I doubt that (0)

Anonymous Coward | more than 5 years ago | (#24952669)

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

Um, it's really a red herring (2, Insightful)

Estanislao Martnez (203477) | more than 5 years ago | (#24952569)

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 (2, Insightful)

Anonymous Coward | more than 5 years ago | (#24952731)

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 (1)

ShadowRangerRIT (1301549) | more than 5 years ago | (#24952973)

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 (0)

Anonymous Coward | more than 5 years ago | (#24953157)

True, here's one blog entry [blogspot.com] 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 (1)

TopSpin (753) | more than 5 years ago | (#24953195)

aren't as fine-grained as they could be

See clone(2) [die.net]. 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.

victory of tabbed browsing - not defeat of threads (1)

schwaang (667808) | more than 5 years ago | (#24952581)

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.

Re:victory of tabbed browsing - not defeat of thre (0)

Anonymous Coward | more than 5 years ago | (#24952773)

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

Re:victory of tabbed browsing - not defeat of thre (1)

ceoyoyo (59147) | more than 5 years ago | (#24952905)

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.

Limitations (4, Insightful)

truthsearch (249536) | more than 5 years ago | (#24952591)

There are some details to Chrome's sandboxing implementation [docforge.com] 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 [chromium.org].

Re:Limitations (1)

jd (1658) | more than 5 years ago | (#24953201)

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.

Self flattery gets you nothing (1)

Nyall (646782) | more than 5 years ago | (#24952621)

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 (2, Insightful)

Safiire Arrowny (596720) | more than 5 years ago | (#24952661)

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 (1)

ceoyoyo (59147) | more than 5 years ago | (#24952949)

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.

Processes in Vista (4, Informative)

hardburn (141468) | more than 5 years ago | (#24952725)

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 (5, Informative)

bluefoxlucid (723572) | more than 5 years ago | (#24952921)

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 (1, Interesting)

dedazo (737510) | more than 5 years ago | (#24953063)

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.

IPCommunications overhead? (2, Interesting)

Urban Garlic (447282) | more than 5 years ago | (#24952735)

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.

Slow to start a process!? (4, Insightful)

Sloppy (14984) | more than 5 years ago | (#24952803)

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!? (1)

ShadowRangerRIT (1301549) | more than 5 years ago | (#24953131)

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!? (0)

Anonymous Coward | more than 5 years ago | (#24953227)

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!? (1)

Just Some Guy (3352) | more than 5 years ago | (#24953281)

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.

Erlang Browser (2, Informative)

bjourne (1034822) | more than 5 years ago | (#24952975)

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

It's different this time around... (1)

Temujin_12 (832986) | more than 5 years ago | (#24953095)

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... (2, Insightful)

ShadowRangerRIT (1301549) | more than 5 years ago | (#24953217)

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 (4, Interesting)

speedtux (1307149) | more than 5 years ago | (#24953109)

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)? :-)

Its not always one process per tab (1)

pfafrich (647460) | more than 5 years ago | (#24953121)

The comic is a lie. The allocation of processes is quite complecated chromes-process-model [marcchung.com]. 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.

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

Anonymous Coward | more than 5 years ago | (#24953125)

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? (1)

ElboRuum (946542) | more than 5 years ago | (#24953215)

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.

Slow? (1)

dadragon (177695) | more than 5 years ago | (#24953343)

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?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...