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 <[email protected]> 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" <[email protected]>님이 작성: 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.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
