There's also a problem when you don't know exactly how much work needs performed. Let's say you're copying two files: foo (1KB) and baz (1GB). A naive implementation may set the progress bar to 50% when foo has been copied, assuming they are close to the same size. Thus, the progress bar would quickly jump to 50% and then slowly go up (assuming the remaining 50% are given accurately based on baz's size). This can be fixed by checking the size of all the files first, but that was merely an example of the "true amount of work unknown" problem.

Were the files over 2GB? I believe that was the IE bug wrt large files: downloading files over 2GB or 4GB (depending on the version of IE) would fail spectacularly including negative progress. It's even documented on kernel.org.

Yeah, I don't normally reply to people who feel the need to resort to lmgtfy.com but have you actually looked at the resolution on the Kinect? It's pretty crappy.

While my comment was sarcastic, I'll bite. Where do you get a 3D scanner that isn't insanely expensive?

It hasn't been available at all since Lion (10.7). Snow Leopard (10.6) didn't have it by default but at least supported it. I wouldn't be surprised to find out that someone has gotten Rosetta from 10.6 to work on {Mountain ,}Lion, but even if it works it's not guaranteed to work after patches or to not just blow up in your face.

I wasn't being entirely serious (obviously you can't email packages, but I didn't really interpret it that way reading it). Perhaps you didn't interpret the sarcasm?

Please, please tell me how I should go about sending a package through e-mail. I'll wait here.

Have you done multi-threaded programming? Everything needs to be re-entrant if it can possibly be called from more than one thread, even if there are different instances/contexts across threads. It's not as simple as "make new thread, hook things up, fire thread".

As I said, everything needs to be re-entrant (which there's no reason for it to be with only one thread), and everything shared across threads needs to be made thread-safe. Files, I/O, and everything with side effects needs to be locked so threads don't stomp on each other. Even with one thread per tab, lots of resources are shared across threads. Perhaps most of the work wouldn't be in the JS engine itself. It doesn't matter. This thread was about it being non-trivial to add threading or multiple processes to a single threaded, single process browser, which there's no way you can argue with.

I think we're talking about completely different things. I agree with all of your points, but I'm saying that it is very non-trivial to run one thread per page, even just for the JS engine, because of the work that has to be done. You're saying that the JS engine itself doesn't need a ton of work, which is correct (although everything must be re-entrant, which does require work unless everything is already re-entrant). Please don't forget that while thread-safe functions aren't required if one context only has one thread, you still need re-entrant functions as soon as you get more than one thread.

Correct, but you were saying that the JS engine itself should have a pool of threads, and that is what I was addressing.

Cookies were merely an example. There are plenty of cases where you need not only re-entrant functions, but thread-safe ones as well. Furthermore, even if the cookie I/O isn't handled by the JS engine itself, it's still irrelevant. If two pages are running (with one JS engine thread per page) and both try to access cookies, you really should hope the cookie accessors are thread-safe. Whether or not the access is done directly from the JS engine doesn't matter much as long as there are multiple threads running simultaneously.

I never claimed that there was IPC specifically in Chrome's JS engine. The point was that, as Chrome uses multiple processes, there is lots of IPC. Specifically, I was pointing out that for someone to add multi-processing to any given browser (in this case Firefox), even just for the JS engine, they'd need to do lots of work to get the IPC working. The only reason Chrome's JS engine doesn't do IPC is because it is part of the same processes as the renderer AFAIK.

I get the concept of a script locking up the JS engine, but my point is that you should always get the unresponsive script warning, with the option to stop it. If you don't, then it's a bug.

I don't know why you say there's no IPC. Chrome uses IPC heavily as documented here. I don't see any way around it, either.

Again, I don't know why you say you wouldn't need thread-safe functions either. Imagine if one thread reads the cookie database, and another writes to it. You bet that needs to be thread-safe... even if you're talking about the JS engine. I'm not a big JavaScript developer, but I know you're still going to need thread safety. Hell, everything would need to be, at the very least, re-entrant. Also, for what it's worth, the OS normally schedules threads with common threading libraries (like pthreads, but NOT GNU Pth which only has one OS thread and does its own scheduling).

Agreed. I don't know if a lawyer approved it, but the letter sure as hell didn't come from one...

IANAL, but I agree with the advice to send a polite but firm "no, unless you can provide a legal backing to your request".

Though this is fairly OT (given that this story is about Java blocking), the script being on another tab shouldn't matter. That sounds like a bug to me. Chrome for me uses far more memory than Firefox, because it spawns at least one process per page (as well as per extension!) but the multi-process model does have nice benefits, such as one page not being able to slow down the rest (unless your CPU is pegged/hard drive is thrashing). I'm also reasonably confident that the JS engine doesn't use threads either. They specifically mention not seeing any benefits in a multi-threaded model, just more complexity. Also, why are separate processes easier? With threads, you need to worry about thread-safe functions and mutexes. With processes, you need an entire IPC system to coordinate things between processes. Personally I find both a pain, but I certainly wouldn't call processes easier at all.

http://winapp2.com/

It doesn't come from CCleaner, CCleaner merely supports it as well. They may have even come up with the format (I don't know), but the file was created by the community not Piriform.

That has never happened to me ever. Any script hogging the CPU should trigger the long-running script warning, giving you the option to kill it. Even when that happens, I still can use the rest of the browser, it's just sluggish. I have no idea why it would block everything else. You're right though, only browsers that use one process per tab are immune to that (such as Chrome).