<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2013-04-04 1:42 PM, Dave Townsend
wrote:<br>
</div>
<blockquote
cite="mid:CAMqKG6sf7v217K0Y5ND77XhWLMyoc8MxPjzDubeLWyTEMDFuGA@mail.gmail.com"
type="cite">
<div dir="ltr">On Thu, Apr 4, 2013 at 7:17 AM, Paolo Amadini <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:paolo.01.prg@amadzone.org" target="_blank">paolo.01.prg@amadzone.org</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 04/04/2013 1.50, Richard Newman wrote:<br>
> And so we have:<br>
><br>
> <a moz-do-not-send="true"
href="http://hg.mozilla.org/mozilla-central/file/default/services/common/utils.js#l112"
target="_blank">http://hg.mozilla.org/mozilla-central/file/default/services/common/utils.js#l112</a><br>
<br>
</div>
If the code comment reflects the reasons behind
implementing this helper<br>
function to delay promise resolution, there are two points
made there:<br>
* Prevent stack accumulation<br>
* Prevent callers from accidentally relying on same-tick
resolution<br>
<br>
The first one already has a patch.<br>
<br>
About the second one, I'd argue that the converse is also
true: if we<br>
had a promise implementation that always waited a tick on
resolution,<br>
callers might accidentally rely on that behavior as well.<br>
<br>
And, code that makes assumptions on one of those behaviors
is probably<br>
already subject to other race conditions, and would be
subject to them<br>
even if it used a structure based on callbacks, and not
promises.<br>
<br>
I think we should have non-delayed resolution when the
module is used<br>
by Toolkit code, to improve performance. Strangely, I seem
to remember<br>
that Irakli mentioned that the Add-on SDK also wanted
non-delayed<br>
resolution (though I can't find the exact post right now).
So, I'm not<br>
sure if there is actually someone that thinks delayed
resolution is<br>
needed for other reasons than to solve the stack
accumulation problem.<br>
</blockquote>
<div><br>
</div>
<div>Strange, I could swear that I talked with people about
async promises and heard only good things, but perhaps as
you say it was purely for stack saving purposes. Is async
resolution the only concern, what about async callback
attachment (which is required by the A+ spec)?<br>
<br>
rnewman seemed to indicate support for this earlier in the
thread, Richard?<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
This is sort of the meta-question around promises. What are we
using them for, and why? My understanding is that promises are
useful precisely because they can be chained like sync calls, while
being/enabling async work. I'm not sure what the value proposition
is for promises if resolution is always immediate, why not use
return/throw like normal JS in that case?<br>
<br>
-- Mike<br>
</body>
</html>