Bringing setTimeout to ECMAScript
Mark S. Miller
erights at google.com
Sun Mar 20 09:24:41 PDT 2011
On Sun, Mar 20, 2011 at 9:17 AM, David Bruant <david.bruant at labri.fr> wrote:
> 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
> >> 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.
I agree with Dave that it's unlikely, but I'm gonna give it a shot anyway.
If I miss, as is likely, then I will make a serious try to get it into
ES-after-next (this naming convention is starting to pinch ;)). So all this
discussion remains relevant at least for the long term. Don't worry about
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss