Responsiveness from "inside" of some programs, not just "between" them

Typical situation - sudden computer overload by “heavy” multimedia content, most frequently this happens after opening a link in a browser leading to some page with lots of video/flash/animations, or after opening some “full-HD” multimedia file inside player, especially if computer at that moment was already near overload (then some programs could become overloaded simultaneously).
Probably the worst case - opening a multi-tabbed browser with auto-starting HD videos in (all or many) multiple tabs (this way behaves well known youtube & many other similar sites), what can happen after watching those videos consequently one by one in different tabs/windows of the same browser (this is useful if data stream ongoing from internet lags to real-time playback speed), then closing/opening that browser with “last session restore” (as usually) on.

So, how will computer with Haiku behave in such a case?
From my common knowledge about BeOS/Haiku I expect the whole OS to be controllable - that is, the ability to switch between different programs & to use those other programs to some extent should remain, but how about responsiveness of that particular overloaded program(s), which as I understand can be from “third parties” regarding OS itself, like Opera browser or VLC player, & which I know from my experience in “windows” as being not responsive - though these programs should be considered enough “progressive” among other similar ones, I don’t expect their BeOS/Haiku versions to be much different in behavior than familiar “windows” versions.
If that “inside” responsiveness doesn’t exist, what’s the big reason of having such a “responsive” whole OS then?
How then this should be so much better than simply controlling different programs by their priority levels in windows task manager - for dealing with this new OS to be worth efforts?

I am not really a Haiku developer but my understanding is that the scheduling behavior inside of Haiku applications should pretty much the same as behavior between programs because they both use the same threading and scheduler to organise themselves.

Of course, the application must use threads appropriately.

You might want to have a read about how Haiku handles threads. This link gives a fairly easy-to-understand overview:
http://www.haiku-os.org/legacy-docs/bebook/TheKernelKit_ThreadsAndTeams_Overview.html

Browsers are a horrible examples at responsiveness. Maybe not Google Chrome as it uses one process per tab, but almost all other browser uses one thread for all things GUI (even slow starting plugins). If that thread needs to wait for a flash-plugin to load or a pdf-reader to start, all the UI in all the tabs are frozen. It’s a horrible bottleneck when it comes to responsiveness.

It’s just one single thread working a FIFO queue, all because the devs thinks synchronization is hard. Avoiding synchronization isn’t easier, it’s just ignoring the problem.

Also this is how Java’s AWT/Swing work, and that hasn’t been a huge hit either. Now instead of multithreading the queues they added SwingWorker to avoid the problem even longer. They really need a BLooper.

/rant off :wink: