I have a CPU intensive work to do and i don't want to degrade the user experience. since web workers (http://ejohn.org/blog/web-workers/) are a new feature and are not supported by all browsers, i thought to open an iframe with an HTML + JS that will do all the dirty work and using some cross-domain communications to pass on the results.
Unfortunately i noticed that the owner of the iframe suffers from the CPU work of the iframe window.
Does this behavior is as designed? is there a way to solve this?
One way to sort of simulate multi-threadedness would be to have a Javascript function do a little bit of work, then call setTimeout with that same function; then the function will do a little work and call setTimeout again, and this cycle will continue forever or until they close the frame or you signal to stop working. MDN has a good example of how to set this up.
Between timeouts, Javascript should not consume any processor time. You might have to play around a little bit to see how long your timeouts should be -- 1ms is probably way too short, but 1s is definitely way too long. Another factor will be the processor speed of the computer running the job, so you might need to do some pseudo-benchmarking on the client's side via Javascript before you can determine how long to delay each time.
JavaScript is single-treaded. Separate tabs or windows may run in separate threads or processes depending on the browser, however you cannot communicate between these windows, so there is no way you can explicitly utilize more than one thread or process in JavaScript.
If it is a question of UI responsiveness, Rushakoff have a good answer. While JavaScript is running, no HTML rendering happens and the UI is not responsive. By using timeouts, control can be released back to the rendering/UI-thread periodically, giving a more responsive feel, even if it still only runs single-threaded.
