Fwd: Future feedback

Mark S. Miller erights at google.com
Tue May 14 17:54:07 PDT 2013


---------- Forwarded message ----------
From: Mark S. Miller <erights at google.com>
Date: Tue, May 14, 2013 at 4:54 PM
Subject: Re: Future feedback
To: Boris Zbarsky <bzbarsky at mit.edu>
Cc: David Bruant <bruant.d at gmail.com>, Sean Hogan <shogun70 at westnet.com.au>,
Jonas Sicking <jonas at sicking.cc>, "public-script-coord at w3.org" <
public-script-coord at 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 at 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



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130514/f00c657c/attachment-0001.html>


More information about the es-discuss mailing list