Standardize ES Worker
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
- `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
- `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
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...
More information about the es-discuss