Interesting. This was written before Google released Chrome. How parallel is Chrome, exactly, compared to the kind of browser described in this blog post?
WebKit, like all engines, is fundamentally single-threaded. Of course, there can be some parallelism added to specific components--in the case of Chrome, multiple tabs (to be more accurate, multiple origins) can execute in parallel--but there's a scalability limit to how far a single-threaded design can take you.
I think multiple "units of related browsing context" [1] would be more accurate; unless I am wrong Chrome uses at most one process per event loop and has one event loop for each set of browsing contexts that can reach each other via the DOM. This means that e.g. an alert in tab A will block scripts in tab B if B.opener == A.
AFAICT IE has a somewhat different design; it seems to really be much closer to "one process per tab", which presumably means that they incur some IPC overhead when different tabs in the same unit of related browsing context have to communicate.
You're somewhat wrong. Chrome will put browsing contexts that normally can't reach each other via the DOM on the same event loop (and in the same process) if it decides it's got too many renderer processes spawned already. Once it does that, they can try to reach each other via the DOM if they have window names.
Oh, so 1:1 between processes and event loops? Doesn't that mean that something blocking in one tab (alert(), sync XHR) might will block tasks in any entirely unrelated tab that just happens to share a process/event loop? That seems rather unexpected.
I can't speak to the exact event loop behavior; I haven't tested it.
Even if you have only one main event loop per process, spinning nested event loops (e.g. the way Firefox does for alert and sync XHR) would let you do things in one tab while another is blocked on an alert or whatnot. I just don't know whether Chrome does that.
