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.
