Oh right, I wasn’t really aware of that; I mean, of the fact, that everything just runs in a single thread, namely the UI thread.

In this case, I am curious on your opinion whether this model is still viable for the long run? In particular, if we expect even more scripting stuff incorporated into future web pages. People are already doing quite complicated computations on the client side. Stuff like parsing JSON strings, calculating spreadsheets, etc is already
there and takes some time. And we can certainly expect a further shift of computations to the client side, I’d guess. I already see my rainbow spinning … 🙂

Are there any long term plans to change that model in WebKit? If so, what’s the way to go? Native “page threads”? A rewritten JS engine with explicit control state? Or both?

is it a bug or feature… are you guys aware of this? (I am not programmer but I am just trying this webkit and it seems to run better than the stable Safari that came out in latest 10.4.x release… which I am glad it was able to load all animations live.)

Got it; this is not BeOS; gotta remember that. 🙂 Makes sense.

A developer can easily display a progress bar of his own, if he so wishes, and I always try to have some kind of progress indicator on tasks that are going to take a while.

I agree this is not a catch-all solution, but this problem in general is down to lazy web developers, there is so much you can do to stop this problem, but people just seem to code for ‘fairly good’ results in IE nowadays.

There’s a difference between blocking by stalling an entire thread and saving off state, yielding and resuming later. If we lived in a world where every page had its own thread that was also independent of the UI thread, you could imagine that it might be ok to just block a “page thread”. We don’t though. (The reality is that pages are typically network-bound enough that there isn’t much benefit to dramatically complicating the code just for a bit of parallelization that would only be useful in very limited circumstances.)

In WebKit (and Gecko) all pages parse and execute script on the main thread (the UI of the browser renders and responds to events on this thread as well). Thus blocking the thread that JS is running on blocks everything except network loading.

“Is there just a single thread that does both the parsing and also the execution of the JS scripts tags? And in this thread, you then manually alternate between the parsing and the JS engine?”

Correct, one thread. There isn’t really “alternation” though. You just run scripts as they are encountered (and loaded) in the page. Scripts block parsing. Even if you did suspend JS, you couldn’t keep parsing that particular page. Therefore there is no benefit to separating into multiple threads based on script execution vs. page parsing.