Bringing setTimeout to ECMAScript
brendan at mozilla.com
Fri Mar 18 16:39:41 PDT 2011
On Mar 18, 2011, at 9:51 AM, Kyle Simpson wrote:
>> As I understand it, this type of thing was kept out of the language
>> proper intentionally, because of its strong dependency on host
>> environment. Some host environments may require tight and overriding
>> control of any event handling system, and exactly which types of
>> events (such as timeouts) are suitable to an environment may vary. A
>> server side host might not want to have to deal with asynchronous
>> activity at all, for instance.
First, as a matter of principle, if it's in ES6 then V8 will implement. So I'm told by people I trust.
Second, what about your embedding is hostile to setTimeout, which is more accurately weakly-isochronous than "asynchronous"?
> I prefer they stay out of the engine, unless the engine is going to completely take care of it. The most important part of the engine "taking care of it" would be blocking the end of the program to wait for any outstanding event loop "turns" that had not yet fired, etc. Seems like that could get really messy.
Read one way (the worst-case interpretation), this shows great confusion about "threads suck", i.e., setTimeout requires no multi-threading. In no scenario would there ever be multi-threaded blocking with races over shared-mutalble state. What gave you this idea?
Read another way, if you mean pseudo-threads implemented with setTimeout never preempt one another but must all end before some larger notion of "the program" ends, then what is the problem, exactly?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss