[whatwg] WebWorkers vs. Threads

[Kristof Zelechovski]

I do not know about implementing setTimeout, this should be rather
straightforward.  However, using setTimeout to do anything serious requires
chunking and yielding as described below, which is an academic exercise
IMHO.  I expect that WebWorkers would give a better abstraction than
setTimeout (like throw vs longjmp).
My example about {++g.i} was about how automatic locking of global variables
is not enough, not about the advantages of using workers.  I would expect
the worker to send "increment g.i" to the main thread, not "set g.i to
$value".  If "increment" is replaced with something infeasible, we have a
problem.  However, I would not be sure incrementing is unlikely to fail;
were it so, WIN32::InterlockedIncrement would be pointless.
Chris

-----Original Message-----
From: Shannon [mailto:shannon at arc.net.au] 
Sent: Wednesday, August 13, 2008 8:51 PM
To: Kristof Zelechovski
Cc: 'Jonas Sicking'; 'WHAT working group'
Subject: Re: [whatwg] WebWorkers vs. Threads

Kristof Zelechovski wrote:
> A background task invoked by setTimeout has to be split to small chunks;
> _yielding_ occurs when each chunk ends (having called setTimeout to
execute
> the next chunk).  It is very hard to code in this way; you have to
maintain
> an explicit stack and create an exit/entry point at every chunk boundary.
> This technique is interesting as an academic exercise only, real-world
> developers will be right to stay away from it.
>   

I'm not sure I get your meaning. If this is how current browsers 
implement setTimeout then how is it "academic"? Also since nobody is 
talking about deprecating setTimeout I don't see how its relevant. 
Whatever happens setTimeout remains an issue that real-world developers 
can't stay away from.