Switching to async/await from Task.jsm/yield

Thom Chiovoloni tchiovoloni at mozilla.com
Fri Mar 17 17:49:10 UTC 2017

On Thu, Mar 16, 2017 at 9:08 PM, Michael Layzell <michael at thelayzells.com>

> I mostly use tasks when writing tests, so I mostly have questions about
> how it's use in that situation will be affected.
> Can we pass async functions everywhere where we use `add_task` in tests
> already? If we can't, is there a tracking bug for converting all of the
> test systems to support it?

We've been doing this in sync's tests (example
since shortly after async/await became available with good results.

The biggest disappointment has been stack traces, which we hoped would
improve some with async/await, but have more or less stayed equivalently
generic and opaque (although it's not clear to me if this is only due to
still having some code using tasks, such as add_task, introducing all that
machinery). But this isn't a regression compared to using Task.js, we had
just been hoping for an improvement (this hope was actually our biggest
motivation for switching, IIRC).

Can you `await` a function created with Task.async such as
> `BrowserTestUtils.withNewTab` during the transition period?

Yes, await generally just expects a function returning a promise (although
I believe its okay to await on a function that returns synchronously, and
that it will be equivalent to it being wrapped with Promise.resolve).

The way it was explained to me is that `let x = await foo(); ...` desugars
to `Promise.resolve(foo()).then(x => { ... })`. I'd certainly appreciate
being corrected if I'm wrong, though.

> How about in ESR52? Will uplifting tests to ESR52 be a painful experience
> due to having to use different tools to write the tests?
Can I pass an async function as the callback argument to things like
> ContentTask.spawn and BrowserTestUtils.withNewTab? How about on ESR52?

If you can pass a function returning a promise in, and have everything do
the right thing, yes. From taking a look at their source, this *seems* to
be the case, but I could be wrong (and I'm sure someone will correct me if
I am).

I don't know if it's okay to use in ESR52, but it does appear that bug
1185106 <https://bugzilla.mozilla.org/show_bug.cgi?id=1185106>, which
implemented async functions, landed in 52, but I also recall being told to
wait for 53 before using it.

> On Thu, Mar 16, 2017 at 7:18 PM, J. Ryan Stinnett <jryans at gmail.com>
> wrote:
>> Sounds like a good change to make from the discussion so far.
>> If there are issues with stack traces, I would assume having more of our
>> code base using async / await is a good way to apply pressure for stack
>> trace improvements (if needed) that will benefit everyone.
>> - Ryan
>> On Thu, Mar 16, 2017 at 5:52 PM, Kris Maglione <kmaglione at mozilla.com>
>> wrote:
>> > On Thu, Mar 16, 2017 at 05:39:06PM -0500, J. Ryan Stinnett wrote:
>> >
>> >> For modules that have already converted, is there any performance
>> change
>> >> (good or bad) between async / await vs. Task?
>> >>
>> >
>> > I haven't noticed any differences either way, but I also haven't done
>> any
>> > explicit profiling. There's definitely a difference in the way we
>> collect
>> > async stacks in async/await code vs. with the Promise.jsm promises that
>> > Task.jsm uses, but that shouldn't show up much on release.
>> >
>> >
>> > On Thu, Mar 16, 2017 at 5:33 PM, Kris Maglione <kmaglione at mozilla.com>
>> >> wrote:
>> >>
>> >> On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote:
>> >>>
>> >>> 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.
>> >>>>
>> >>>>
>> >>> +1
>> >>>
>> >>> I've already started doing this in places where using Task.jsm was
>> >>> unwieldy, and it's improved things tremendously.
>> >>>
>> >>
>> _______________________________________________
>> dev-platform mailing list
>> dev-platform at lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20170317/5dbb1e4a/attachment.html>

More information about the firefox-dev mailing list