Standardize ES Worker

Isiah Meadows isiahmeadows at gmail.com
Thu Oct 27 22:18:47 UTC 2016


Here's my idea for a new API, leveraging ES modules and the proposed (stage
2) dynamic `import()` proposal. It also supports the shared memory proposal.

1. Add a new `import.fork(script): Promise<Worker>` method-like expression
that loads the worker and resolves when done/rejects if it couldn't for
some reason.

  - `receive` is a function that accepts a message and may optionally
return a value or thenable to it, which is cloned and returned to the
worker's `send` call.

2. Add the following methods/properties:

  - `worker.terminate()` - Terminate the worker
  - `worker.send(message, sharedBuffers?)` - Send a message and return a
Promise to its result.
  - `worker.receive(message)` - A setter for a function that accepts a
message and may optionally return a value or thenable to it, which is
cloned and returned to the worker's `send` call.

3. Load the worker as a module. The following exports are used specially,
and they're both optional:

  - `initialize(parent)` - A function that accepts a `parent` with two
methods: `parent.terminate()` to terminate the worker's own thread and
`parent.send` being equivalent to `worker.send` above (except in the other
direction). This is called immediately after the parent's wrapping promise
resolves.
  - `receive(message)` - Receive messages from the parent, and works
similarly to `worker.receive`.

I chose syntax for similar reasons Domenic chose syntax for his dynamic
import proposal, for example, the modules can be statically resolved, which
enables prefetching.

I also chose modules to leverage themodule system to my advantage, in
particular to avoid adding new globals.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161027/ed9e555c/attachment.html>


More information about the es-discuss mailing list