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

<br></div><div>Curiously, this is how Ken <<a href="https://www.usenix.org/conference/usenixfederatedconferencesweek/composable-reliability-asynchronous-systems-treating" target="_blank">https://www.usenix.org/conference/usenixfederatedconferencesweek/composable-reliability-asynchronous-systems-treating</a>> and NodeKen <<a href="http://research.google.com/pubs/pub40673.html" target="_blank">http://research.google.com/pubs/pub40673.html</a>> 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!<div>

<br><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Tue, May 14, 2013 at 7:03 AM, Boris Zbarsky <span dir="ltr"><<a href="mailto:bzbarsky@mit.edu" target="_blank">bzbarsky@mit.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 5/14/13 9:04 AM, David Bruant wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<a href="http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0167.html" target="_blank">http://lists.w3.org/Archives/<u></u>Public/public-script-coord/<u></u>2013AprJun/0167.html</a><br>
</blockquote>
<br>
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.<br>
<br>
I would be strongly opposed to specifying something that requires only two FIFO queues.<span><font color="#888888"><br>
<br>
-Boris<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br>    Cheers,<br>    --MarkM
</font></span></div></div></div></div>
</div><br><br clear="all"><div><br></div>-- <br>    Cheers,<br>    --MarkM
</div>