W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2008

[whatwg] WebWorkers vs. Threads

From: Kristof Zelechovski <giecrilj@stegny.2a.pl>
Date: Thu, 14 Aug 2008 09:50:11 +0200
Message-ID: <85C88D90F1D24ACE84116E21A7F76A47@POCZTOWIEC>
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@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.
Received on Thursday, 14 August 2008 00:50:11 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:04 UTC