Linked by David Adams on Tue 23rd Dec 2008 16:40 UTC, submitted by judgen
Internet & Networking Most Firefox users don't realize that Firefox's current existence is owed almost exclusively to its search partnership with Google wherein Mozilla Corp receives a portion of ad revenue from Google queries initiated from Firefox's search bar. This revenue amounts to tens of millions of dollars. Internet users the world over, who are currently reaping the benefit of a renewed browser war with exciting innovation instead of Microsoft-dominated stagnation, can thank Google for that state of affairs. But now that Google has itself entered the fray with Chrome, what does that mean for the Firefox/Google relationship?
Thread beginning with comment 341394
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Reinventing the wheel :(
by microFawad on Wed 24th Dec 2008 17:35 UTC in reply to "RE[3]: Reinventing the wheel :("
microFawad
Member since:
2005-12-09

I don't know what MS did for IE, but changing an application to be built on processes instead of threads likely means rebuilding it from the ground up


"IE8 uses the Loosely Coupled Internet Explorer (LCIE) architecture and runs the browser frame and tabs in separate processes"

http://en.wikipedia.org/wiki/Internet_Explorer_8#Performance_and_st...

Reply Parent Score: 1

sbergman27 Member since:
2005-07-24

"IE8 uses the Loosely Coupled Internet Explorer (LCIE) architecture and runs the browser frame and tabs in separate processes"

I'm no MS fan, but it is wonderful to see the thread-mania of the last years finally starting to dissipate. Even the POSIX world has had a pretty good "threading infection" going. There are so many other, better, ways to do concurrency. Processes and the actor model. Fibers. I personally, like the multi-process, multiple fibers per process model. All the advantages of processes and threads while avoiding most of the additional memory/create/destroy overhead of processes and almost completely sidestepping all the nightmares of the "shared all" approach of threads. Message passing is where it's at. Share nothing, by default, and explicitly pass that which needs to be shared through a clean interface. And use the shared memory (but nonconcurrent!) fibers only where they are needed for performance reasons.

Edited 2008-12-24 18:12 UTC

Reply Parent Score: 3