In IE8 and Chrome, Processes Are the New Threads 397
SenFo writes "To many of the people who downloaded Google Chrome last week, it was a surprise to observe that each opened tab runs in a separate process rather than a separate thread. Scott Hanselman, Lead Program Manager at Microsoft, discusses some of the benefits of running in separate processes as opposed to separate threads. A quote: 'Ah! But they're slow! They're slow to start up, and they are slow to communicate between, right? Well, kind of, not really anymore.'"
Processes (Score:5, Interesting)
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]
Chrome = slow as hell (Score:3, Interesting)
There's another cost to seperate processes (Score:3, Interesting)
AV slowing the start of each process is really going to cause a performance hit.
Re:Processes (Score:3, Interesting)
Re:Deja vu (Score:3, Interesting)
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:Cheap and Dirty Crash Isolation... (Score:3, Interesting)
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.
IPCommunications overhead? (Score:3, Interesting)
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:Processes (Score:1, Interesting)
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.
Another Benefit: Killing Bad Pages (Score:3, Interesting)
Re:Processes in Vista (Score:1, Interesting)
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:Deja vu (Score:5, Interesting)
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.
quite ironic (Score:5, Interesting)
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:Only one benefit discussed: isolation (Score:3, Interesting)
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:Processes (Score:5, Interesting)
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:Deja vu (Score:3, Interesting)
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:Only one benefit discussed: isolation (Score:4, Interesting)
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:Processes (Score:3, Interesting)
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.)
google comic strip (Score:2, Interesting)
Re:Processes (Score:5, Interesting)
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 (Score:5, Interesting)
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 (Score:2, Interesting)
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.
Addendum... (Score:1, Interesting)
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.