Slashdot Mirror
In IE8 and Chrome, Processes Are the New Threads
SenFo writes "To many of the people who downloaded Google Chrome last week, it was a surprise to observe that each opened tab runs in a separate process rather than a separate thread. Scott Hanselman, Lead Program Manager at Microsoft, discusses some of the benefits of running in separate processes as opposed to separate threads. A quote: 'Ah! But they're slow! They're slow to start up, and they are slow to communicate between, right? Well, kind of, not really anymore.'"
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]
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.
AV slowing the start of each process is really going to cause a performance hit.
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.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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.
Socialism: a lie told by totalitarians and believed by fools.
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.
2*3*3*3*3*11*251
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!
The wheel is turning, but the hamster is dead.
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.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
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.
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)? :-)
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
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
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.
thegodmovie.com - watch it
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.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
*plays the Apogee theme song music*
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.