Le 20/03/2011 16:56, David Herman a écrit : >> 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. > You don't need vats for this, just a top-level driver loop. > >> Despite the inelegancy, could it work? > No way -- polling isn't just inelegant, it starves your processor. You'd at > least have to expose some sort of sleep() command, no? Starving the processor is what I called "inelegant" :-) I was trying to give an example of a setTimeout implemented with Vats+pure ES5 (no sleep). Otherwise, be sure that I would do differently. Sleep is one idea. Having another passive-wait primitive like the delay() example of the concurrency strawman is another idea.
>>> 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. > Fair enough. Sorry if I was a little hyperbolic. No worries. > (moved) > Now, an implementor may not want to have to implement an event queue. I won't > try to speak for implementors. But setTimeout introduces a different overall > program control flow model than the old start-compute-exit model. Most JS > embeddings use the interactive, event queue-based model, but it sounds like > at least Kyle's doesn't. > > But that alone should probably not stop us from moving ahead with > concurrency. If an engine wants to provide a sequential JS, they can probably > just do so and say they're conformant with everything except for the > concurrency parts. Or maybe we can highlight the concurrency parts of the > spec and say a sequential JS doesn't have to implement them. This probably > isn't too important. >> 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). > No. That's part of my point. We may not be able to standardize the event loop > for ES.next. As I say, I'm open to doing it at some point, and if we add > concurrency features we'll have to specify the event queue as well, but I > think there's a high probability that we won't get to this in time for > ES.next. We have a *lot* on our plate. Actually, this is the part I was missing. My initial e-mail was based on the assumption that an event loop will be part of ECMAScript.next through Promises. And my point was that if it's the case, adding time to it and implementing setTimeout on top of that will not be hard. But if this is not happening, then my idea comes too early, indeed. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
