<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 18, 2011, at 9:51 AM, Kyle Simpson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><blockquote type="cite">As I understand it, this type of thing was kept out of the language<br></blockquote><blockquote type="cite">proper intentionally, because of its strong dependency on host<br></blockquote><blockquote type="cite">environment. Some host environments may require tight and overriding<br></blockquote><blockquote type="cite">control of any event handling system, and exactly which types of<br></blockquote><blockquote type="cite">events (such as timeouts) are suitable to an environment may vary. A<br></blockquote><blockquote type="cite">server side host might not want to have to deal with asynchronous<br></blockquote><blockquote type="cite">activity at all, for instance.<br></blockquote><br>Speaking as someone who has written and currently maintains a *synchronous* server-side JavaScript environment (based on V8), I attest to the statement that I would *not* like it if V8 had `setTimeout()` (...etc) in it, because unless V8 were going to take care of that completely black-box for me, then I'd have to either disable such interfaces, or figure out some more complicated functionality in my environment to handle the "concurrency".<br></div></blockquote><div><br></div>First, as a matter of principle, if it's in ES6 then V8 will implement. So I'm told by people I trust.</div><div><br></div><div>Second, what about your embedding is hostile to setTimeout, which is more accurately weakly-isochronous than "asynchronous"?</div><div><br></div><div><br><blockquote type="cite"><div>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.<br></div></blockquote></div><br><div>Read one way (the worst-case interpretation), this shows great confusion about "threads suck", i.e., setTimeout requires no multi-threading. In <b>no</b> scenario would there ever be multi-threaded blocking with races over shared-mutalble state. What gave you this idea?</div><div><br></div><div>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?</div><div><br></div><div>/be</div></body></html>