Le 19/03/2011 16:39, David Herman a écrit : >>> It seems to me there are a couple pieces to Mark's concurrency >>> proposal. One part is formalizing the event queue that already exists. >> Is this already done in the current proposal? Because I haven't found >> it. > > Sorry, I guess I should say, we can't add concurrency without having > it be compatible with existing event queue semantics, which likely > requires formalizing that in Ecma-262. > >> Regardless, this work of formalizing the already existing event queue >> has already been done by the WHATWG: >> http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loops > > Yeah, I know. > >> I think it would be a mistake to start the formalization work from >> scratch since a decent part of the work has already been done. > > Duplicating specs certainly sucks. But it seems nonsensical to me to > specify things that rely on the event queue without having the event > queue in the semantics. Maybe the spec would have to cross-reference > WHATWG? Ugh. > > Actually, wait a minute -- I think I disagree with you here. WHATWG > specifies the specific event queue of the browser. Node.js has its own > event queue. (...) Actually, we agree. I never said that TC39 should copy/paste the event-loop section written by the WHATWG. I said that WHATWG has done some on work specifying what currently happens in browser (joining with your idea of "be[ing] compatible with existing event queue semantics"). One idea would be to see what they've done, get inspired and specify the event queue in ECMAScript. Node.js implementation would be another source of inspiration. But the WHATWG has written a spec, not an implementation which is subject to change at anytime. That's the value I was seeing in particularly studying WHATWG event queue before working on adding event queue to ECMAScript (which, as you say in your next point is compulsory in a way or another to define pre-emption-less concurrency).
> I don't think there's any way to specify "run-to-completion" (which is > really just a hand-wavy way of saying "no pre-emption," which is > itself really just a way of saying "sequentialized event queues") > without specifying event queues. > > But I still don't see why standardizing timers, and only timers, is so > important. Node implements them, and they work. What problem are we > fixing? > >> Once, I read the concurrency proposal with in mind "can setTimeout be >> implemented with what is in this proposal?". I have found the timeout >> section >> (http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#timeouts) and >> I thought "awesome!"... until I realized that this example is itself >> using setTimeout (which is consistently implemented in most >> ECMAScript-based environments but isn't itself part of any ECMAScript >> version). > > Why do you think setTimeout is so special? It seems like just another > host-environment API like, say, onClick. It provides access to one of > the host environment's system service. I agree that it can be considered as an host-environment API. However, setTimeout seems to be widely implemented. I think it makes more sense to specify it within ECMAScript. It could be an occasion to specify what happens when you're in strict mode and you do setTimeout("alert(this)", 0). Is this string interpreted as strict eval code? There is a spec hole here. Bringing setTimeout to ECMAScript would be an occasion to answer the question and not let implementors do whatever they prefer or even to forget the question. This would avoid yet another de facto standard. >> However, the tiny brick/element/component/part that is missing to >> implement "time event" ("clock event"?) is to take time into account >> in the proposal. > > How is this element's absence any more important than the absence of, > say, onMouseover? Granted, it has more applicability than just the > browser (since node.js uses it), but as Kyle's already pointed out, > some embeddings may not want to expose the system clock. Actually, a conforming ES5 implementation implements Date.now(). In that condition, it's hard to not expose the system clock, or am I missing something? This is giving me a (terrible) idea to implement setTimeout. We could have two vats. One asks the second to resolve some promise after a certain amout of time. The second loops and resolve the promise when the delay is passed (measured as a delta between Date.now() at request reception and in the loop test. I warned on the terrible aspect of the idea). On resolution, the function passed to Q.when in the first vat is called. Despite the inelegancy, could it work? >> And I intuit it wouldn't be that hard to add it. > > It's not exactly a walk in the park. Have you ever tried to formalize > real time? Einstein had a few words to say about this subject. :-) I am aware of the theorical problem. However, it has never prevented people from including "time" in different languages specifications, or implementing libraries using the concept of "time". There are also people out there writing "performance benchmarks" where they "measure time"! Joke aside, there is no need to formalize real time. For Date.now(), ES5 says: "The now function return a Number value that is the time value designating the UTC date and time of the occurrence of the call to now." About setTimeout and setInterval, WHATWG says: "This API does not guarantee that timers will fire exactly on schedule. Delays due to CPU load, other tasks, etc, are to be expected." In my opinion, these are sufficiently accurate approximations of real time so that implementors can know what to do while admitting they've given up on formalizing real time and don't want to dig any further the topic. > I still just don't get this whole thread. > But I still don't see why standardizing timers, and only timers, is so > important. Node implements them, and they work. What problem are we > fixing? So, to summurize a couple of things that has been said: * With the work on strawman:concurrency, the event loop concept will be added to ECMAScript.next (regardless what is decided for setTimeout). * Standardizing setTimeout based on the event loop is basically just adding a timing component to the event loop. * "Real time is already in ECMAScript 5 through Date.now()" * Standardizing setTimeout is the occasion to fully specify the string-as-a-first argument case to avoid de facto standards before strict mode or Harmony opt-in is widely deployed. I was about to say something about security, but since Mark replied, it will be more acurate to reply to him on the topic. David _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
