- From: Kristof Zelechovski <giecrilj@stegny.2a.pl>
- Date: Thu, 14 Aug 2008 09:50:11 +0200
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