I too thought I was being polite, apart from my initial objection to being treated as though I have no knowledge of how computers work at this level.
I see you don't refute any of my post, much of which pulls holes in your explanation.
I'll address them. I was at work and unfortunately didn't have time to make an extended reply.
Second, if a modern OS uses time-slicing to apportion time between threads then an awful lot of CPU time is going begging and there is a lot of inefficiency while threads wait for their next slice.
This is incorrect. It is the most efficient method of providing fair concurrent execution of the many threads in an OS (excluding certain specific real-time critical systems)[6].
If you read any book on Operating Systems[5], or read documentation on OS Schedulers (Linux[1], UNIX, ...), they use pre-emptive multi-tasking [1] (where time-slicing is used in the general sense to mean thread scheduling to apportion CPU time for many threads to execute, rather than any specific TS algorithm) .
For instance, Linux scheduling is implemented with extremely efficient algorithms[2][3] that also account for priority and other weighting factors to determine how much of the processing resources are given to any particular processor[4], and without it there is no way for the hundreds of threads to progress concurrently in an practicable manner.
[1]
http://oreilly.com/catalog/linuxkernel/chapter/ch10.... (these are older than the CFS algorithm, but still used in many distros)
[2]
http://doc.opensuse.org/products/draft/SLES/SLES-tun...
[3]
http://en.wikipedia.org/wiki/Completely_Fair_Scheduler
[4]
https://gustavus.edu/+max/os-book/updates/CFS.html
[5] Andrew Tanenbaum's Operating Systems book is a bible, great stuff. Highly recommend it for the intrepid computing scientist.
[6]
http://en.wikipedia.org/wiki/Scheduling_%28computing%29
Third, I'd be very surprised if the OS is telling the processor which core to use for any given thread.
When a de-scheduled (or new) thread reaches the moment that it must be scheduled to run, the OS will decide which processor (or core) to dispatch the thread to. The given thread's state to will be set in that processor, and execution is resumed (i.e. it must ensure that the register values are correct for the given thread, and it transparently continues executing as if it had never been de-scheduled). For very specific use-cases certain programs may have a processor affinity set, but this is rare as it is usually more efficient to let the OS decide, and spread the load dynamically.
OS scheduling algorithms are intelligent enough to schedule threads wherever the most resources are available.
There are plenty of exceptions for edge-case usage, I don't want to bore people with it here by writing a huge amount, but there are reams of resources on the Internet for those who are interested

.
Whilst the browser as a whole will use multi-threading, the tabbed view implementation may for some reason not do so.
It is almost certain that it would have to (use threads, or an equivalent concurrent mechanism), otherwise the stuff rendered in the content pane would freeze as you interacted with the tab. Most of those threads will do very little taxing work however.
hth
edit: missed a point that needed a response
Edited by deleted (Sat 25-Jun-11 03:01:49)