More flexibility in the ECMAScript part?

David Bruant bruant.d at gmail.com
Thu Apr 18 05:40:57 PDT 2013


Le 18/04/2013 13:28, Alex Russell a écrit :
> On Thu, Apr 18, 2013 at 8:48 AM, David Bruant <bruant.d at gmail.com 
> <mailto:bruant.d at gmail.com>> wrote:
>
>     Le 18/04/2013 09:40, Anne van Kesteren a écrit :
>
>         On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr.
>         <jackalmage at gmail.com <mailto:jackalmage at gmail.com>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130418/6b5737ab/attachment.html>


More information about the es-discuss mailing list