<div dir="ltr">On Thu, Apr 4, 2013 at 7:17 AM, Paolo Amadini <span dir="ltr"><<a 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 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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If there are no strong objections to non-delayed resolution, I'd like<br>
to proceed with finalizing that implementation (for now, you can see<br>
a prototype in bug 810490). If someone can find a good way to isolate<br>
the returned Promise objects so that consumers don't have access to<br>
internals, I'd be glad to implement that, so that we can plug the new<br>
implementation seamlessly into the Add-on SDK as well.<br></blockquote><div><br></div><div>If we put the implementation in toolkit then SDK can just wrap it to only expose the minimal API we want.<br></div></div></div></div>