Re: More flexibility in the ECMAScript part?

On Thu, Apr 18, 2013 at 6:11 AM, David Bruant <bruant.d@gmail.com> wrote:

> Le 18/04/2013 14:59, Jorge a écrit :
>
>  On 18/04/2013, at 14:40, David Bruant wrote:
>>
>>  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.
>>>
>>
Agreed. Further, ES can't avoid specifying event loops, perhaps even in an
ES6 timeframe!! It would indeed be unfortunate if we need to specify this
in ES6. But I don't see how we can specify module loaders without doing so.
The only alternative I see is that we postpone module loaders till ES7,
which many of us (including myself) would find unpleasant.

Although I do not want to see module loaders postponed till ES7, for
completeness I will mention one further advantage of doing so. Currently,
module loaders are specified in terms of callbacks. Were they postponed, we
could instead specify their API in terms of promises. The similarity to the
spec dependency dilemmas motivating this thread are indeed striking.



>>> For now, I'm aware of only these types of interactions:
>>> 1) add a message to the queue LIFO-style (which is the default?)
>>>
>> This isn't neccessary,
>>
>>  2) add a message to the queue FIFO-style also known as "add for the next
>>> turn"
>>>
>> This is the only one needed,
>>
> If you only have this one, then you can end up in situations where user
> inputs are never processed. The 1) is necessary. I assume some re-ordering
> policies/primitives might be necessary too.


LIFO isn't the way the browser specs deals with this issue. Rather, both
the browser specs[*] and, lately, nodejs have adopted a two priority event
loop, which can be accurately modeled (and implemented) as two fifo queues;
call them "inner" (or high priority) and "outer" (or low priority). An
outer turn thus consists of a sequence of inner turns. In the browser,
rendering only happens as an outer turn. Object.observe and DOMFutures are
both careful to queue events only in the inner queue, so all the
observation events queued in an outer turn happen within inner turns at the
end of that outer turn without the possibility of any intervening rendering.

IO events at least usually queue in the outer queue. Is this always the
case? Do any IO events queue in the inner queue?

The Q API has historically queued only in the outer queue. The Q community
has lately been debating this issue and tending towards having local Q
events queue in the inner queue. Of course, distributed messaging, being
layered on IO, would still queue only in the outer queue, but this doesn't
seem to create any conflicts.


[*] The HTML5 specs adopt different terminology which obscures the
similarity of the two levels of event loop queueing. But it is equivalent
to this uniform two-level model.


>
>
>  3) remove a message (clearTimeout which cancels a message added via a
>>> setTimeout message).
>>>
>> and this has nothing to do with the events queue.
>>
> Can you develop your 3 answers, please? Throwing agreement/disagreement
> without providing reasons doesn't help the debate to move forward.
> Timeouts do interact with the event loop at least in the WHATWG spec (see
> step 10 of [1] as an example)
>

You don't need to account for cancellation in terms of event queue
manipulation. And I agree with (what I believe to be) Jorge's position,
that it is less clean to do so. Rather, you can just think of the queued
event as having the behavior "do this if it isn't cancelled" and the
cancellation as setting a cancellation state to be so tested by that queued
event once it fires. Of course, if implemented this way, it would fail to
reclaim as much storage. But that's not an observable difference, so the
spec can simply use the simpler model.




>
> David
>
> [1] http://www.whatwg.org/specs/**web-apps/current-work/**
> multipage/timers.html#dom-**windowtimers-settimeout<http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-windowtimers-settimeout>
>
>
-- 
    Cheers,
    --MarkM