Future feedback

Mark Miller erights at gmail.com
Tue May 14 17:59:00 PDT 2013


AFAICT, the microtask queue is just another output queue, and the strict
priority of the microtask queue over other queues is just a policy choice
of which outgoing queue to service next. The input queue model could not
guarantee strict priority without creating a two level queue. The outgoing
queue model keeps this separate with no loss of generality. Cool.


On Tue, May 14, 2013 at 5:54 PM, Mark S. Miller <erights at google.com> wrote:

>
>
> ---------- 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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Text by me above is hereby placed in the public domain

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


More information about the es-discuss mailing list