RFC: Async workers and new task implementation

[tptee]

Adds a Worker trait that supports bidirectional, streaming asynchronous work in a Rust thread. Also updates the Task trait to a convenience wrapper for single-shot work on a Rust thread. The existing Task implementation, which runs work on the libuv thread pool, exists at Task::spawn_uv.

Rendered Implementation

[tptee]

Well, Node 10's new experimental worker threads really dropped a bomb on this RFC: https://nodejs.org/api/worker_threads.html

Although "native addons are not supported yet," I can't imagine it will take long for that support to materialize. This makes me think that the best course of action here is to close the RFC and drop the implementation.

Benefits of waiting on worker threads:

• No libuv build matrix wrangling and esoterica to remember (we'll probably still want bindgen for N-API)
• No added crossbeam dependency.
• No custom API; consumers just load a native extension into a worker thread and use postMessage.

The worker threads aren't technically "Rust threads," but if they have their own libuv event loop and are running Rust code, does it matter?

[dherman]

@tptee I wanted to come back around to wrap up this discussion! First I wanted to respond to this question:

The worker threads aren't technically "Rust threads," but if they have their own libuv event loop and are running Rust code, does it matter?

Theoretically, maybe not, but creating a JavaScript Worker is heavyweight from a performance perspective. There should be a smaller primitive for creating a Rust thread and being able to have that thread communicate back to JavaScript (asynchronously).

That said, it looks like neither this high-level API nor the low-level API of #13 quite found the abstraction level we needed, and #25 found the sweet spot. Thanks for helping us explore the design space!