web worker threads and window.settimeout

[wolverine]

Hi Friends,

Today I was reading about web worker threads at
https://developer.mozilla.org/En/Using_DOM_workers supported by
Firefox 3.5. They allow web content to run in background in different
threads. But isn't that the same facility(in a roundabout way)
provided by 'settimeout' function. window.settimeout also allows us to
execute a function in background threads with affecting UI. So why do
Firefox folks had to go for web worker threads supports if the only
thing they wanted was to do jobs in background.

Thanks for Reading,
Kiran.

 

[Martin Honnen]

Today I was reading about web worker threads at
https://developer.mozilla.org/En/Using_DOM_workers supported by
Firefox 3.5. They allow web content to run in background in different
threads. But isn't that the same facility(in a roundabout way)
provided by 'settimeout' function. window.settimeout also allows us to
execute a function in background threads with affecting UI. So why do
Firefox folks had to go for web worker threads supports if the only
thing they wanted was to do jobs in background.

setTimeout simply sets up a timer to run some code after a specified
time. That code runs in the same thread as the code calling setTimeout.
So there is no use of different threads with setTimeout.

 

[Jorge]

Hi Friends,

Today I was reading about web worker threads athttps://developer.mozilla.org/En/Using_DOM_workerssupported by
Firefox 3.5. They allow web content to run in background in different
threads. But isn't that the same facility(in a roundabout way)
provided by 'settimeout' function. window.settimeout also allows us to
execute a function in background threads with affecting UI. So why do
Firefox folks had to go for web worker threads supports if the only
thing they wanted was to do jobs in background.

workers are separate JS processes () running in separate threads,
workers execute concurrently,
workers don't block the UI,
workers allow you to extract up to the last drop of juice from a
multicore cpu,
workers can be dedicated (single tab) or shared among tabs/windows,
workers can be persistent too (coming soon): they'll keep running
after the browser has quit.

See "Google I/O 2009 - Google's HTML 5 Work: What's Next?":
<

>
starting @0h:13m:56s

 

[wolverine]

setTimeout simply sets up a timer to run some code after a specified
time. That code runs in the same thread as the code calling setTimeout.
So there is no use of different threads with setTimeout.

Thanks a lot for your reply Martin. Since the code is always going to
run in the main thread, does this mean that there is no gain in
performance or UI responsiveness obtained by running a code with
setTimeout ? I already read your post on a similar topic at
http://groups.google.com/group/comp...unning+too+long,+what+to+do?#0424fcf63dd1869e.
I assume even the use of setTimeout will result in UI getting blocked
at a later point of time.

 

[wolverine]

workers are separate JS processes () running in separate threads,
workers execute concurrently,
workers don't block the UI,
workers allow you to extract up to the last drop of juice from a
multicore cpu,
workers can be dedicated (single tab) or shared among tabs/windows,
workers can be persistent too (coming soon): they'll keep running
after the browser has quit.

See "Google I/O 2009 - Google's HTML 5 Work: What's Next?":
<

>
starting @0h:13m:56s

Jorge, That really helped. I was also reading an incomplete discussion
involving you on the muticore cpu.
http://groups.google.com/group/comp...unning+too+long,+what+to+do?#0424fcf63dd1869e.