Re: Future feedback

I see. I was thinking primarily about incoming queues whereas this
formulates the issue primarily in terms of outgoing queues. Rather than
have a non-deterministic interleaving of events into the incoming queue,
which then services them later, this just moves the non-deterministic
choice as late as possible, at the point when the next turn is ready to
start. This effectively removes the notion of an incoming queue from the
model.

Curiously, this is how Ken <
https://www.usenix.org/conference/usenixfederatedconferencesweek/composable-reliability-asynchronous-systems-treating>
and NodeKen <http://research.google.com/pubs/pub40673.html> treat the
persistent storage of distributed messages. The incoming queues are
ephemeral, outgoing messages are not dropped until receipt has been
acknowledged, and messages are not acknowledged until processed by a turn
that has been checkpointed. On restart a different interleaving may be
chosen, which the "incoming queue" model would have a harder time
accounting for. I like it. AFAICT, this is a better way to specify
communicating event loops in all ways. Thanks!



On Tue, May 14, 2013 at 7:03 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 5/14/13 9:04 AM, David Bruant wrote:
>
>> http://lists.w3.org/Archives/**Public/public-script-coord/**
>> 2013AprJun/0167.html<http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0167.html>
>>
>
> I should note that the description of the browser event loop in that
> message is wrong.  It does not have only two FIFO queues in the specs, or
> in implementations.  In particular, see task sources.
>
> I would be strongly opposed to specifying something that requires only two
> FIFO queues.
>
> -Boris
>
>


-- 
    Cheers,
    --MarkM