Switching to async/await from Task.jsm/yield

Kris Maglione kmaglione at mozilla.com
Fri Mar 17 19:39:27 UTC 2017


On Fri, Mar 17, 2017 at 10:19:02AM -0700, Dave Townsend wrote:
>One issue I have just spotted is that Task.jsm uses a JavaScript
>implementation of promises under the hood while async/await obviously uses
>our native implementation in the JS engine. This may mean the two have
>slightly different characteristics. That shouldn't matter for new code
>written but may cause problems as we attempt to automatically rewrite older
>code and tests make bad assumptions.

With the exception of async stacks, the two have basically the same 
characteristics these days. Promise.jsm uses native promises to schedule 
its flush loop these days, so the two should behave in the same way.

The only particular issue I've run into is that some test code assumes it 
will always have a JS caller on the stack for reporting, which isn't 
always the case when called as a native promise resolution handler.

>On Thu, Mar 16, 2017 at 3:29 PM, Dave Townsend <dtownsend at mozilla.com>
>wrote:
>
>> For a long time now we've been writing JS code that waits for promises
>> using Task.jsm and generator functions. Recently though the JS team added
>> support for the JS standard way of doing this, async/await:
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/
>> Reference/Statements/async_function
>>
>> Writing code in standard JS is always better for the web, makes it easier
>> to onboard new engineers and allows for better support in developer tools.
>> So I'd like to propose that we switch to the standard way of writing these
>> functions immediately. New code should use async/await instead of Task.jsm
>> going forwards.
>>
>> Florian has some rough plans to automatically rewrite existing usages of
>> Task.jsm to the standard JS forms so for now don't worry much about going
>> and submitting patches to fix up existing code. Once that is done we can
>> remove Task.jsm from the tree.
>>
>> Does anyone object to any of this?
>>



More information about the firefox-dev mailing list