Draft: Demo potential upcoming Neon APIs

[kjvalencik]

Hello!

I'm a maintainer on the Neon project and we are considering a couple of major [breaking] changes as we ramp up to the v1.0 release. Since skia-canvas is a significant user of Neon, I wanted to get your thoughts.

Two proposed changes that impact this project are the rewritten Borrow API and JsPromise/Tasks.

• Borrow RFC
• JsPromise/Task RFC

For the most part, these are cosmetic changes and should not impact how the code executes. However, there is one significant difference in this PR. Previously, async tasks were being spawned using rayon::spawn which uses the rayon threadpool. However, this uses cx.task(...) which uses the Node worker pool.

Since these are CPU intensive tasks, I don't expect it to have a significant difference; however, I'm not sure if rayon optimizes execution from its own threads better than other pools. If the previous functionality is preferred, the implementation can be swapped to cx.channel() and Channel::settle_with.

I would appreciate your thoughts. Thanks so much for the support!

Note: This PR is only meant as a discussion topic and should not be used. It uses an alpha version of Neon.

[kjvalencik]

I'm not sure why the Promise returned by Node-API is a different class than global.Promise. It might have something to do with jest? When I test a simple case locally promiseFromNeon instanceof Promise is true.

[samizdatco]

I'm a wholehearted fan of the TypedArray support (and am grateful for any opportunity to remove a cx.borrow(…, ||) closure).

On the promise/task side of things, the syntax is really nice—quite the improvement! My only concern is a little wariness about having two separate thread pools potentially fighting with one another. Given how likely it is for client code to be using rayon, I can see an argument for keeping as much of neon's background processing in that same hopper if it means the scheduler can make better decisions. I don't actually have any idea whether libuv and rayon would end up in a resource tug-of-war in practice, but it seems like something that would be worth testing...

[kjvalencik]

Thanks for the feedback @samizdatco! That's some good points about thread pools. Switching to keep using rayon is a little more boilerplate, but I think still an ergonomics win.

let channel = cx.channel();
let (deferred, promise) = cx.promise();

rayon::spawn(move || {
    /* ... */

    channel.settle_with(deferred, |cx| { /* ... */ });
});

Ok(promise)

I'll hold making that change for now because the API is being bikeshed a bit. A couple of questions:

• Would you expect a panic to automatically reject the promise?
• When sending a Deferred across a channel to be settled (resolved/rejected) on the main thread, which of these is more clear?

  channel.settle_with(deferred, |cx| { /* ... */ });
  
  // or
  
  deferred.settle_with(&channel, |cx| { /* ... */ });

[samizdatco]

Closing this after 2 years of happily using the suggested 1.0 changes