Standardize ES Worker

Park Hyeonu nemo1275 at gmail.com
Mon Oct 31 03:44:01 UTC 2016


+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/6b8e8b10/attachment-0001.html>


More information about the es-discuss mailing list