Standardize ES Worker

Isiah Meadows isiahmeadows at gmail.com
Mon Oct 31 12:48:53 UTC 2016


I just specified some basic semantics. That sounds like a good idea, but I
feel it should just remain a WHATWG extension for now. Technically, you can
still manage ids to ensure it ends up properly coordinated (you already had
to do this when working at scale).

On Sun, Oct 30, 2016, 23:44 Park Hyeonu <nemo1275 at gmail.com> wrote:

+1 for `import.fork()`, especially for deep integration with module syntax.

Anyway I think we still need to create Independent message channel which
can be transferable, for use cases like returning sequence of messages,
central worker manager, etc.

I agree with your approach to avoid new global variable as much as
possible. To respect this, how about `Channel#createChannel` method?

```
const [chan, remoteChan] = worker.createChannel()
worker.send('newchan', remoteChan [remoteChan])
```

2016. 10. 28. 오전 7:18에 "Isiah Meadows" <isiahmeadows at gmail.com>님이 작성:

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/20161031/7c7ab6fd/attachment.html>


More information about the es-discuss mailing list