Microsoft IE8 and Google Chrome - Processes are the New Threads
Sponsored By
I happened to install Google Chrome (Alpha) the same day I installed Internet Explorer 8 (Beta). I noticed immediately, as I'm sure many of you have, that both browsers isolate tabs in different processes.
Unix folks have known about the flexibility of forking a process forever. In Unix, fork() is just about the easiest thing you can do. Also, fork()ing in Unix will copy the whole process and all variables into a new space. Everything after the fork happens twice. Multitasking made easy.
In Windows, you call CreateProcess() and you don't get a copy or clone. You just start up a whole new universe, starting from the very beginning - NOT from the call to CreateProcess().
What processes in Windows and Unix do have in common is that they each get their own protected virtual memory space. They are all alone and isolated. If a process crashes it's less of a crisis than if a thread within a process crashes.
(In .NET, AppDomains are like mini-processes, but they just aren't as completely isolated as a process is, so you can still bork an AppDomain enough that the whole process dies.)
Why does all this matter? Well, back in the day, most folks on Windows would recommend that developers interested in multi-tasking use threads. There's even been talk about fibers (really tiny threads within threads...like superstrings ;) ) However, darnnit, processes are easy.
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. There's this thing called Moore's Law that keeps marching on. Making a new process and talking to it in any of the myriad IPC (Inter-process Communication) methods available just isn't that much of a problem these days. Just open up Process Explore and enter "Tree View" sometime to see how many programs you use every day are actually multiple .exe's working together.
You can learn more about IE8 and how their multiple-process model works in both IE7 and IE8. (IE7 had this process isolation feature also...except one tab per security zone.)
You can learn more about Chrome and how they talk between their multiple "Render" processes in this architectural overview. They are using named pipes if you were wondering how Chrome talks to itself.
Tab/Process Isolation
I'll open up an instance of IE8 and open one tab with cnn.com and other with hanselman.com. I'll do the same with Google Chrome. Here's what Process Explorer shows.
Why are some of the processes brown? Those are jobs, a new kind of process added in Windows 2000. Jobs are made with CreateJobObject and AssignProcessToJobObject. You can also get a Job using CreateProcess as unless you specify the CREATE_BREAKAWAY_FROM_JOB flag. Jobs in Windows can be controlled as a group and resource limits can be set on them. You can learn more about Jobs and why they can be more secure up on MSDN.
Crash Protection
The whole point of having more than one process for a browser is for crash protection. I've had every browser I've ever used crash in one tab while I was hoping to keep my other 49 tabs open.
Let's blow away some processes manually and see what the browsers do. I'll blow away the non-job process for Chrome.exe.
_3.png)
Looks like that process hosted Flash. See how the Flash object has been replaced on the cnn.com home page with a sad puzzle piece? Cool. Chrome hosts plugins in their own process also.
Lets blow away another Chrome.exe process. Ah, looks like that particular process was rendering hanselman.com. It's been replaced by a sad-page icon.
_3.png)
OK, let's blow away an IE8 process....
Ah, looks like the FIRST time a page crashes in IE8, it dumps the process, the tab disappears, then the tab comes back automatically to try to put the user where they were before. I'll kill the new process...
Looks like IE8b2 will only try a few times to automatically restore the bad tab then it gives up and gives its equivalent sad-tab and says "the website continues to have a problem." Also cool. This beta includes an option to turn "automatic crash recovery" off or on.
If the parent process dies (or, in this case, I kill it myself!) then I'll get a dialog from IE8 offering to restore the last session.
I'll get this similar message in Google Chrome.
Very cool. Now I have two browsers that I can open up a buttload of tabs in and not worry about maxing-out process limits or having one bad tab messing up the whole bunch.
PS: If you are poking around in Chrome, try visiting pages like: "about:network", "about:stats", "about:dns" and "about:memory"
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hosting By
Google Chrome plugin-isolation still need a lot of work though. If you are on a single-core machine, the plugin process can still locks all the chrome.exe process up.
And you wouldn't want to be searching for that single process that host Adobe Flash, you'd just close all the chrome.exe you could find.
And you wouldn't want to be searching for that single process that host Adobe Flash, you'd just close all the chrome.exe you could find.
Double K - Ya, I was wondering how one was supposed to know which process the plugin was in. I guess you'd use the Chrome Task Manager, but at that point you're already pretty technical.
Damien - Let's pass that info on to the IE8 team.
Damien - Let's pass that info on to the IE8 team.
The ironic thing is that before browsers had tabs, every window was already in it's own process (most of the time). When tabs came along, they were touted as a great invention for keeping all your pages in one process, to save memory. Seems like we've come full circle.
On a sidenote, your comment box is broken on IE8. I can't see what I'm typing without looking at the Live Preview.
On a sidenote, your comment box is broken on IE8. I can't see what I'm typing without looking at the Live Preview.
This functionality is missing from IE7, But a plug in named IE7Pro comes to the rescue with a lot of other features.
http://www.ie7pro.com/
http://www.ie7pro.com/
Ilia Jerebtsov wrote:
> before browsers had tabs, every window was already in it's own process
Browsers as far back as I remember (my first website was early 1994), have spawned new windows in the _same_ process whenever you ctrl-N, or File->New Window or even click on click on the browser in the Quick Launch toolbar down by the Start button. This was so that new windows (and popup windows) shared session cookies. Only when you double clicked on the .exe, or selected the browser from the Start->Programs menu did a new process start.
> before browsers had tabs, every window was already in it's own process
Browsers as far back as I remember (my first website was early 1994), have spawned new windows in the _same_ process whenever you ctrl-N, or File->New Window or even click on click on the browser in the Quick Launch toolbar down by the Start button. This was so that new windows (and popup windows) shared session cookies. Only when you double clicked on the .exe, or selected the browser from the Start->Programs menu did a new process start.
Try entering about:internets in Chrome's address bar. On a non Vista machine you'll find an Easter Egg like page.
If you really want some fun with chrome, open up a few tabs, and then in one of the tabs type about:%
Their crash recovery doesn't quite work in this case.
Their crash recovery doesn't quite work in this case.
Unfortunately, I've had Chrome "hang" or slow down my entire system to such an extent that even Windows stopped responding. Of course, if I wait long enough, it would catch itself and give me the sad face. In practice, I don't have the patience to wait 2 minutes for it to come back. Faster to kill the entire thing and start from scratch.
These crashes have been mostly flash-related. I never had this happen in Firefox - possibly because I used a flash-blocker/ad-blocker.
Never used IE7 or IE8 so no experiences there...
These crashes have been mostly flash-related. I never had this happen in Firefox - possibly because I used a flash-blocker/ad-blocker.
Never used IE7 or IE8 so no experiences there...
I don't know about in IE8 (haven't installed it), but in Chrome middle clicking on a link appears to load the tab in the same process as the parent tab. Since that's the only way I open links, Chrome has locked up all my tabs more than once.
Looking through the other comments, I saw the one from Double K - talking about a plugin crash taking out Chrome entirely on a single-core machine. Perhaps that is my problem - I am using Chrome only on my old home single-core laptop.
One thing you may not have noticed about Internet Explorer 8 is that they added support for alternative style sheets. A browser that supports style sheet switching will allow the user to control the display of the page.
Google Chrome also has about:cache and about:histograms
Google Chrome also has about:cache and about:histograms
Damien - I would disagree with the change in wording. In fact, I think Google should change theirs to match IE's. With all the advancements in the modern browsers, it is more often the page itself that is causing the crash. This is especially so with so much application logic in JavaScript. I believe it is high time that slow, non-responsive, and buggy websites take the blame that is rightfully theirs. Now that we are able to see which websites drink up memory like a frat-boy does beer, we can hold such sites accountable for their own programming. Until now, when a user experiences a browser crash, they can't be sure which site caused it, and generally just blame the browser. Let's put the blame back where it belongs.
One major difference in the process isolation is that Chrome assigns a process to a specific tab. In IE8 any explorer exe can respond to any tab event. So Chrome's method isolates better from a security perspective (e.g. something in a tab "seeing" what's in another tab).
Matt wrote:
> Chrome assigns a process to a specific tab
> ....
> So Chrome's method isolates better from a security perspective
There are many caveat's with Chrome's current isolation. It will only ever create 20 processes. Thereafter, tabs are assigned randomly to one of the 20 processes. Frames (same origin or not) are always in the same process. Hyperlinking from one frame to another does not change process. Some cross-domain JavaScript calls which should be allowed (on the window object) currently do not work.
So Google have a lot of work to do to sort all this out. I have no idea how this compares with IE8's LCIE.
> Chrome assigns a process to a specific tab
> ....
> So Chrome's method isolates better from a security perspective
There are many caveat's with Chrome's current isolation. It will only ever create 20 processes. Thereafter, tabs are assigned randomly to one of the 20 processes. Frames (same origin or not) are always in the same process. Hyperlinking from one frame to another does not change process. Some cross-domain JavaScript calls which should be allowed (on the window object) currently do not work.
So Google have a lot of work to do to sort all this out. I have no idea how this compares with IE8's LCIE.
I seem to remember that Netscape Navigator 2.x on OS/2 Warp did something like that with new browser windows. At least one window crashing didn't bring down the other windows. The contemporary Netscape Navigator 3.x on Windows was not as forgiving. (I remember we called Netscape Navigator 2.x for OS/2 "Netscape/2" back then.)
Anyway, not sure I understand the difference between fork() and CreateProcess() completely. I have used fork(), but I have never written anything for Win32 (except via Visual Basic 6 and REALbasic).
Anyway, not sure I understand the difference between fork() and CreateProcess() completely. I have used fork(), but I have never written anything for Win32 (except via Visual Basic 6 and REALbasic).
Ya, I'm realizing that Chrome's process isolation isn't THAT shiny...I've got 90 tabs open right now, and only 20 processes. So there's that cap RichB mentioned. Also, one domain == one process. Bummer.
This will make IE8 b2 *completely* unresponsive, not just one tab:
Chrome deals *much* better with this. Even Firefox and Safari are able to find their way out of it after 10 or so seconds. IE8 b2 just sits there, pale and unresponsive.
I posted the same question on IEBlog recently (it was first comment on the post) but nobody said a word :(
<div id="test"></div>
..
t = document.getElementById("test");
while(true)
{
t.innerHTML += "a";
}
Chrome deals *much* better with this. Even Firefox and Safari are able to find their way out of it after 10 or so seconds. IE8 b2 just sits there, pale and unresponsive.
I posted the same question on IEBlog recently (it was first comment on the post) but nobody said a word :(
I'm curious to know more about the javascript virtual machine they are creating. Seems to me that they are looking for a more robust javascript environment for Google Apps (docs, gmail, cal, maps, etc.). At first glance (read totally unscientific) Chrome does appear to run these apps faster than FF 3.0 and IE 7.0, but I don't have IE 8 Beta installed to compare to that.
@Todd:
Chrome's V8 benchmarks are biased towards recursion. Perhaps google tends to use more recursive javascript in their products? I compared the performance of IE8's javascript engine vs. V8 on Chrome using http://dromaeo.com and found IE8's performance to be better. The dromaeo tests are a more realistic real world javascript usage.
My question is, Do users really care any more how fast javascript is anymore?
Chrome's V8 benchmarks are biased towards recursion. Perhaps google tends to use more recursive javascript in their products? I compared the performance of IE8's javascript engine vs. V8 on Chrome using http://dromaeo.com and found IE8's performance to be better. The dromaeo tests are a more realistic real world javascript usage.
My question is, Do users really care any more how fast javascript is anymore?
Regarding the auto-save of the browser session, the Opera browser has had it for years so this can't be such a big deal (to me at least).
Plus, do any of these browsers have Recycle Bin / Trash can? (The feature that lets you open a mistakenly closed tab). Opera does.
Plus, do any of these browsers have Recycle Bin / Trash can? (The feature that lets you open a mistakenly closed tab). Opera does.
Andrei, Chrome has a list of recently closed tabs that you can "unclose"
It's nice to see people are starting to get the idea in 2008. I think the rest of us figured out that threads were really neat and a really bad idea while OS/2 was still around. Call me a cynic, but when you fork you can still share open listen sockets, constant data that doesn't get written to, without incurring any extra memory overhead. All threading buys you is lots of time wasted calling lock mutex, usually on resources that will never conflict (let us all take a moment to bow to roguewave). And this is better? Like all things that are considered 'progress' we have taken a mighty step in complexity for the sake of the next big thing.
I have a similar rant on OO programming. When was the last time you actually (and I mean really did it, not just talked about or planned on doing it) made use of all that abstraction you over-designed into your application. Except for connecting different databases and one or two other biggies, most of that abstraction is a big waste of time and complexity. Hopefully everybody will wake up to that too sometimes soon.
I have a similar rant on OO programming. When was the last time you actually (and I mean really did it, not just talked about or planned on doing it) made use of all that abstraction you over-designed into your application. Except for connecting different databases and one or two other biggies, most of that abstraction is a big waste of time and complexity. Hopefully everybody will wake up to that too sometimes soon.
Stu:
OO isn't about abstraction. It's about modelling real-world artifacts into OO types. I find that when I take a procedural application and make it OO, I loose 30% of the code. I've done this on a couple of significant applications. So OO often makes code simpler and less abstract.
For example, strongly typing with a state pattern is infintely less abstract (more concrete) than representing those states as a set of integers.
OO isn't about abstraction. It's about modelling real-world artifacts into OO types. I find that when I take a procedural application and make it OO, I loose 30% of the code. I've done this on a couple of significant applications. So OO often makes code simpler and less abstract.
For example, strongly typing with a state pattern is infintely less abstract (more concrete) than representing those states as a set of integers.
FOR MORE DETAILS Visit http://www.googlechromeinfo.com
I think it's ironic that the longer Microsoft goes on, the more it becomes like *nix.
Way to go making front page on slashdot, Scott. You've come a loooong way, baby. ;)
Given enough time and given enough money Microsoft will eventually invent Unix.
i managed to crash chrome today in such a way that i can't kill the process in task manager. what am i to do in this case besides restarting windows?
I suspect the next step (afer isolating a browser tab in a dedicated proccess) is to enable blocking (synchronous) ajax requests.
This is a feature that require that every page is in a different thread/process.
This is a feature that require that every page is in a different thread/process.
I would like to see real arguments against the fact that processes are slow. I actually would be very pleases to read a paper about this... it would be very interesting. Because processes ARE slower, and just saying "well, maybe they are not" doesn't say anything.
Context switches are quite expensive, and since every process runs on a different address space, depending on how the operating systems implements the memory management and the location of the data in the virtual memory, cache locality can be a big problem, and the operating system may need to flush the cache every time a context switch occours due to cache misses or conflicts (specially when running on horrible architectures, as the P4).
Of course that on these days, a few more cycles don't affect the performance that much, and since most of the programmers don't know how to free memory properly (they are used to this monster called garbage collector and are too lazy to write good software), it looks like a good idea to isolate every tab in a different process.
But I still would like to see a real paper about this, with real arguments and profiling numbers.
Context switches are quite expensive, and since every process runs on a different address space, depending on how the operating systems implements the memory management and the location of the data in the virtual memory, cache locality can be a big problem, and the operating system may need to flush the cache every time a context switch occours due to cache misses or conflicts (specially when running on horrible architectures, as the P4).
Of course that on these days, a few more cycles don't affect the performance that much, and since most of the programmers don't know how to free memory properly (they are used to this monster called garbage collector and are too lazy to write good software), it looks like a good idea to isolate every tab in a different process.
But I still would like to see a real paper about this, with real arguments and profiling numbers.
@Scott,
What's the connection per-host limitation on Chrome? Is it configurable or hard-coded?
And what's the impact - or potential impact - of the 20-process limit on the connection limit?
Lori
What's the connection per-host limitation on Chrome? Is it configurable or hard-coded?
And what's the impact - or potential impact - of the 20-process limit on the connection limit?
Lori
Cadu: yes, processes are slower, context switches are slower, but as you point out: it doesn't really matter anymore. Back in the old days when we counted cycles, it mattered, but the fact is as much as it pains the purist to see all this waste and bloat and layering, it's far far cheaper to buy a faster intel chip than to pay you or me more good money to write better software. That's just the reality. You'll find life becomes a lot less stressful if you stop caring. The only place it matters anymore is banking. And that's a lot of stress. Not worth it unless you're really into money.
And consider: you've got multiple cores or god forbid actual multiple processors. Who's context switching?
And again, I've played the thread game, and unless you really take a lot of care to do it just right (again, more expensive programming time) you end up wasting a lot of time locking and unlocking resources that you wouldn't have to waste time doing, if you'd just waste the memory on another process.
On my silly little apple II, a INC accumulator took 2 cycles, a 1Mhz chip, I could do a lot of those in one second.
Now imagine a 4 Ghz chip with all that fancy read ahead stuff that they do that I don't even keep up on anymore. Explain to me why anybody should really even care wasting a few billion cycles here and there on a garbage collector.
And consider: you've got multiple cores or god forbid actual multiple processors. Who's context switching?
And again, I've played the thread game, and unless you really take a lot of care to do it just right (again, more expensive programming time) you end up wasting a lot of time locking and unlocking resources that you wouldn't have to waste time doing, if you'd just waste the memory on another process.
On my silly little apple II, a INC accumulator took 2 cycles, a 1Mhz chip, I could do a lot of those in one second.
Now imagine a 4 Ghz chip with all that fancy read ahead stuff that they do that I don't even keep up on anymore. Explain to me why anybody should really even care wasting a few billion cycles here and there on a garbage collector.
I am curious about the way authentication is handled when each tab has a separate process. I frequently want to enter a username and password and then open a couple of links maintaining this authenticated session.
In the quick tests I have done, it appears that Chrome is happy to pass the username and password to each new tab, but IE8 requires you to re-enter username and password.
I'm not sure which way is better. I wonder if there is a security vs convenience trade-off. I think I like the convenience.
I imagine this issue will become increasingly important with the spread of web applications. I also wonder how authentication for ajax calls is handled.
In the quick tests I have done, it appears that Chrome is happy to pass the username and password to each new tab, but IE8 requires you to re-enter username and password.
I'm not sure which way is better. I wonder if there is a security vs convenience trade-off. I think I like the convenience.
I imagine this issue will become increasingly important with the spread of web applications. I also wonder how authentication for ajax calls is handled.
About 10 years ago, I tried an experiment to determine which was more efficient: 1 process with 20 threads or 20 processes with 1 thread each
Much to my surprise (once I corrected for cache line effects) there was essentially no difference in performance.
Obviously the 20 processes took up more memory, but the measurements I took indicated that an inter-process context switch took about the same amount of time as an intra-process context switch.
I wouldn't be too worried about the CPU overhead between threads and processes.
Much to my surprise (once I corrected for cache line effects) there was essentially no difference in performance.
Obviously the 20 processes took up more memory, but the measurements I took indicated that an inter-process context switch took about the same amount of time as an intra-process context switch.
I wouldn't be too worried about the CPU overhead between threads and processes.
Cadu wrote: "Context switches are quite expensive, and since every process runs on a different address space, depending on how the operating systems implements the memory management and the location of the data in the virtual memory, cache locality can be a big problem, and the operating system may need to flush the cache every time a context switch occours due to cache misses or conflicts (specially when running on horrible architectures, as the P4)."
Processors without simultaneous multithreading do a context switch every time they switch between threads. Then you lose the locality benefits within one thread anyway, as the stuff loaded by the new thread starts to flush out the old thread's stuff from cache.
"Moore's Law" unfortunately doesn't apply to RAM capacity, which thus far has failed to scale with number of cores and will only fail harder. This is because DRAM is power intensive (it can easily dominate the power usage of an efficient CPU). Considering the growth of the mobile and netbook markets, it's surprising to me that browser architects are planning on using MORE memory.
Processors without simultaneous multithreading do a context switch every time they switch between threads. Then you lose the locality benefits within one thread anyway, as the stuff loaded by the new thread starts to flush out the old thread's stuff from cache.
"Moore's Law" unfortunately doesn't apply to RAM capacity, which thus far has failed to scale with number of cores and will only fail harder. This is because DRAM is power intensive (it can easily dominate the power usage of an efficient CPU). Considering the growth of the mobile and netbook markets, it's surprising to me that browser architects are planning on using MORE memory.
Interesting.... I wrote about the isolated processes (Sand-boxed tabs) a few days ago too. Weird that Microsoft does not tout it more. I was shocked to discover it while looking at Process Explorer.
http://blog.aggregatedintelligence.com/2008/09/ie8-beta-and-chrome-initial-thoughts.html
http://blog.aggregatedintelligence.com/2008/09/ie8-beta-and-chrome-initial-thoughts.html
I've said it time and time again, Microsoft's process model is wrong, they build a system optimized for threading, so a lot of software running on Windows uses that model. Which is exactly the reason you don't want Windows on your server. Because if there is any security problems, there is no proper isolation. Now it turns out this is also a good model for the desktop, duh. They should have gone with the Linux process model, optimize for processes, keep things simple, threading is just added complexity.
PS Completely agree about not using OO-programming as well, don't add complexity, keep things simple and flat. If it's to complex, you're doing it wrong !
PS Completely agree about not using OO-programming as well, don't add complexity, keep things simple and flat. If it's to complex, you're doing it wrong !
The Chrome team have published an interesting security report on the process isolation thing if people are interested. See
http://crypto.stanford.edu/websec/chromium/chromium-security-architecture.pdf
Its 10 densely packed pages long and has a paragraph that discusses IE8's approach.
While the separate process per tab thing is very interesting in Chrome (and the ability to drag drop tabs, leaving the YouTube video or whatever running) - the fact that the rendering engine runs separately to the browser kernel (which has the file system access) is very interesting.
Also - the choice of installing Chrome into %AppData% is very interesting. It means that a user doesn't need admin rights to install the browser but it does mean that the installed browser executables do not get the same protection from malware that something installed in %ProgramFiles% would in Vista. Not sure if this is overall a good or bad thing yet - just interesting :-)
http://crypto.stanford.edu/websec/chromium/chromium-security-architecture.pdf
Its 10 densely packed pages long and has a paragraph that discusses IE8's approach.
While the separate process per tab thing is very interesting in Chrome (and the ability to drag drop tabs, leaving the YouTube video or whatever running) - the fact that the rendering engine runs separately to the browser kernel (which has the file system access) is very interesting.
Also - the choice of installing Chrome into %AppData% is very interesting. It means that a user doesn't need admin rights to install the browser but it does mean that the installed browser executables do not get the same protection from malware that something installed in %ProgramFiles% would in Vista. Not sure if this is overall a good or bad thing yet - just interesting :-)
Chrome is looking good but it's early days still. Can´t wait for it to be ported to Mac OSX
This article is a perfect example of how useless all Microsoft error messages are. You can't ever find or fix the actual problem because their error messages never contain any specific information. the problem is so consistently bad that it can only have been done as a conscious design decision. Probably made by some clueless Marketing exec. who thinks everyone in the world is as technically uninformed as (s)he is.
That whole 'dumb user' mentality is fine if you're one of the 0.00000001% of people who are using a PC for the first time, but for the rest of us it always makes using MS products very annoying.
The presumption that the user is necessarily ignorant and stupid is getting much worse with every new version of Windows, especially vista. its one of the biggest reasons I now mostly use Linux.
That whole 'dumb user' mentality is fine if you're one of the 0.00000001% of people who are using a PC for the first time, but for the rest of us it always makes using MS products very annoying.
The presumption that the user is necessarily ignorant and stupid is getting much worse with every new version of Windows, especially vista. its one of the biggest reasons I now mostly use Linux.
This article is a perfect example of how useless all Microsoft error messages are.
I don't think it's useless. The actual "cause" of the problem is something the IE developers need to worry about, why should you care? The crash report gets sent to them (assuming you allow it) so what more do you want to know?
I don't think Linux is any better, anyway. I use Ubuntu at home, and one of the most frustrating things with it is when you've got a CD in the drive, it won't let you eject the CD if something has a file open, but it won't tell you what file, or what has a handle to it (certainly not that I could find anyway). Windows is actually better in this respect -- at least on Windows, I can press the "Eject" hardware button on the drive and the CD will eject. Linux just pops up a message saying the device is busy and it can eject it...
More from Google on the Multi-process architecture in Chrome for people that are interested:
http://blog.chromium.org/2008/09/multi-process-architecture.html
http://blog.chromium.org/2008/09/multi-process-architecture.html
I had a discussion with a developer where he supported the thread approach and said that the process approach is wrong. But then I remembered that if you're using java threads in linux (at least with the sunvm) it always creates new process for your threads. So, while developers thought they were doing threads programming they were actually using more processes.
Dean: I think it's a matter of how you look at it, I've had windows ( apps and/or windows itself) crash after removing a CD from the drive.
Anyway you can see what files are open, if you goto system monitor, in the menu bar you'll find: Monitor and the first item would be: search for open files. Also you can list all open files of a process there too.
Anyway you can see what files are open, if you goto system monitor, in the menu bar you'll find: Monitor and the first item would be: search for open files. Also you can list all open files of a process there too.
hey Scott, did you notice the 'Task Manager' in Chrome ? For me it's more than enough to know (and Kill) the process that is not responding, also tells me the memory each tab/process is consuming. v cool.
@Lennie
Not to completely hijack this thread, but if OO is making your applications more complicated, you are using it wrong :) The whole point of OO is to make programming simpler, by breaking up concepts into individual pieces which are easy to reason about in isolation. This makes it easier to understand any particular segment of the application without having to understand the whole thing to the same degree.
Not to completely hijack this thread, but if OO is making your applications more complicated, you are using it wrong :) The whole point of OO is to make programming simpler, by breaking up concepts into individual pieces which are easy to reason about in isolation. This makes it easier to understand any particular segment of the application without having to understand the whole thing to the same degree.
I'm a tester at Zillow.com.
@Mark Lindell, I can tell you for sure that I care about javascript performace. As we work on making more application like websites, such as Zillow, differences in javascript performance are noticable. While there is a lot of heavy lifting that we do on the server-side to make "thin" clients perform reasonbaly well, some things can only be determined from the client-side on demand.
I can't find the source now, but I remember reading that IE will only "optimize" for 3 processes. I guess this is a bit like the 20 process limit of Chrome, but these shared instances still are limits. I think I prefer Chrome's system since it allows you to tear off threads and recombine them in other browser groups. I can't tell you how many times I've wanted to move a tab from one window to another and Chrome lets me do precisely that. I think that there are many things Google still has to do before I will use Chrome as my primary browser, but I already use it on a regular basis as my "research" browser. Work tends to stay in IE and I tend to use FF for test, but Chrome gives me a place to keep private things (much like Flock did), and then with the ability to tear off tabs, it really is ideally suited for researching different topics. Each browser group then becomes a topic.
@Mark Lindell, I can tell you for sure that I care about javascript performace. As we work on making more application like websites, such as Zillow, differences in javascript performance are noticable. While there is a lot of heavy lifting that we do on the server-side to make "thin" clients perform reasonbaly well, some things can only be determined from the client-side on demand.
I can't find the source now, but I remember reading that IE will only "optimize" for 3 processes. I guess this is a bit like the 20 process limit of Chrome, but these shared instances still are limits. I think I prefer Chrome's system since it allows you to tear off threads and recombine them in other browser groups. I can't tell you how many times I've wanted to move a tab from one window to another and Chrome lets me do precisely that. I think that there are many things Google still has to do before I will use Chrome as my primary browser, but I already use it on a regular basis as my "research" browser. Work tends to stay in IE and I tend to use FF for test, but Chrome gives me a place to keep private things (much like Flock did), and then with the ability to tear off tabs, it really is ideally suited for researching different topics. Each browser group then becomes a topic.
Comments are closed.
[)amien