Le 18/04/2013 13:28, Alex Russell a écrit :
On Thu, Apr 18, 2013 at 8:48 AM, David Bruant <[email protected] <mailto:[email protected]>> wrote:

    Le 18/04/2013 09:40, Anne van Kesteren a écrit :

        On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr.
        <[email protected] <mailto:[email protected]>> wrote:

            Note that Futures are entirely expressible in today's JS
            semantics.

            (Not to say that it shouldn't be reviewed by the language
            gurus here,
            just saying.)

        JavaScript does not have an event loop (as I mentioned
        elsewhere) so
        that is not true. HTML defines the event loop model and processing
        model for any asynchronous JavaScript execution. Lifting that
        up to
        JavaScript seems difficult.

    What do you expect to be difficult? I foresee that it's going to
    be *a lot* of work on both sides (W3C/WHATWG & TC39) to move this
major piece from one place to another without breaking anything.

I don't think that's true at all. We're never going to be able to standardize on ONE event-loop, nor even be able to require that implementations have them...indeed, we've been pretty careful in designs like Object.observe() to avoid dependencies on it.

What we can (and should) do is to say "if you have an event loop, some primitives behave in this way relative to turns". That doesn't require breaking anything.
I believe the ES spec should provide the primitives of what type of interaction with the message queue is allowed and what isn't. This set of primitives would obviously contain all the interactions allowed today by HTML5.

For now, I'm aware of only these types of interactions:
1) add a message to the queue LIFO-style (which is the default?)
2) add a message to the queue FIFO-style also known as "add for the next turn" 3) remove a message (clearTimeout which cancels a message added via a setTimeout message).

At least it's not possible to remove an arbitrary message.

There are probably reordering policies that need to be described as well.

I'm not saying these primitives should necessarily be exposed to the runtime directly, but at least to other specs.

Are there other types of interactions with the message queue I'm forgetting?

David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to