W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Future feedback

From: Mark S. Miller <erights@google.com>
Date: Tue, 14 May 2013 16:54:58 -0700
Message-ID: <CABHxS9hzq8nhM6irqA46jrn1O2igF0BPD+CGBBpb06byst7JiA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: David Bruant <bruant.d@gmail.com>, Sean Hogan <shogun70@westnet.com.au>, Jonas Sicking <jonas@sicking.cc>, "public-script-coord@w3.org" <public-script-coord@w3.org>
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
Received on Tuesday, 14 May 2013 23:55:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC