>> 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. Others may as well. The unofficial agreement of JS has always been, no matter where you embed it, it should never have pre-emption. So what we would be specifying is the rough concurrency framework required of any JS embedding. In other words, it would be a more abstract specification of event queues, of which WHATWG event queues are a valid implementation. 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 still just don't get this whole thread. > 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. > 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. >> As for event queue semantics, I think in principle that Ecma-262 is a >> reasonable place to specify it. It doesn't rely on specifics of the browser, >> and Node.js is a testament to that. (Besides, a non-interactive setting >> could probably be modeled as a trivial event queue, i.e. one with just a >> single "run the program" event.) I'm not sure whether this is worth trying >> to accomplish in time for ES.next, though. > Does the fact that some event loop formalization work has already been done > by the WHATWG within Standard HTML change your opinion on the matter? Not really, no. Dave
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
