Rosetta is not even installed on Mac OS X by default anymore.
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
1) The USPS is NOT a monopoly. You are free to send your mail/packages via FedEx, UPS, DHS, local parcel and gasp e-mail.
Please, please tell me how I should go about sending a package through e-mail. I'll wait here.
Explain how that scenario has different requirements from the current implementation in browsers, from the thread POV.
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.
Generally, JS is single-threaded, especially within a page. You'll note there's no "thread" type, class, nor anything else you can access from within the browser (to stay on topic, Node.js etc are not in scope) You can achieve multi-threading via Ajax, which does run a separate I/O and "thread" in JS, and can cause some interesting behavior (race conditions) if you have multiple Ajax calls affecting the same element set.
Correct, but you were saying that the JS engine itself should have a pool of threads, and that is what I was addressing.
Going further - the I/O for cookies is handled underneath the JS engine, the JS engine itself, at least as far as page rendering and UI interaction goes, is single threaded.
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.
as far as the JS engine goes, there is no IPC, and even in Chrome
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.
Louise Kinane
Customer Experience Manager | Head of UK Operations | Piriform
IANAL, but I agree with the advice to send a polite but firm "no, unless you can provide a legal backing to your request".
Winapp2.com is the official website of Winapp2.ini, an addon for CCleaner, System Ninja, and BleachBit that adds support for over one thousand additional programs.
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.
If A = B and B = C, then A = C, except where void or prohibited by law. -- Roy Santoro