On Sun, Mar 20, 2011 at 9:17 AM, David Bruant <david.bru...@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 > 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. > 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 "too early". > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
