Re: Standardize ES Worker

Inline. On Mon, Oct 31, 2016, 10:33 Boris Zbarsky wrote: > On 10/31/16 8:42 AM, Isiah Meadows wrote: > > When the worker has finished loading, so you can send and receive > messages > > OK, what about a worker that when it loads just starts and infinite loop > and starts

Re: Standardize ES Worker

On 10/31/16 8:42 AM, Isiah Meadows wrote: When the worker has finished loading, so you can send and receive messages OK, what about a worker that when it loads just starts and infinite loop and starts sending you messages (but obviously never expects any messages from you, since it's in an

Re: Standardize ES Worker

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

Re: Standardize ES Worker

Inline On Thu, Oct 27, 2016, 21:42 Boris Zbarsky wrote: > On 10/27/16 6:18 PM, Isiah Meadows wrote: > > 1. Add a new `import.fork(script): Promise` method-like > > expression that loads the worker and resolves when done/rejects if it > > couldn't for some reason. > > What does

Re: Standardize ES Worker

+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

Re: Standardize ES Worker

On 10/27/16 6:18 PM, Isiah Meadows wrote: 1. Add a new `import.fork(script): Promise` method-like expression that loads the worker and resolves when done/rejects if it couldn't for some reason. What does "done" mean in this case? - `worker.send(message, sharedBuffers?)` - Send a message

Re: Standardize ES Worker

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` method-like expression that loads the worker and resolves when done/rejects if it couldn't for some

Re: Standardize ES Worker

OK, so if fetch Response can't be cloned that was my bad, sorry for confusion. On 27 Oct 2016 8:12 p.m., "Boris Zbarsky" wrote: > On 10/27/16 1:47 PM, Michał Wadas wrote: > >> It's already handled by current specification as structured clone >> algorithm. >> > > Sort of. Not

Re: Standardize ES Worker

On 10/27/16 1:47 PM, Michał Wadas wrote: It's already handled by current specification as structured clone algorithm. Sort of. Not all things can be structured cloned. A fetch Response, for example, can't be, and that's what the example being discussed was using... -Boris

Re: Standardize ES Worker

It's already handled by current specification as structured clone algorithm. Though having binary serialisation format would be cool. On 27 Oct 2016 6:38 p.m., "Boris Zbarsky" wrote: > On 10/27/16 10:02 AM, Frankie Bagnardi wrote: > >> It doesn't really need to clone anything,

Re: Standardize ES Worker

On 10/27/16 10:02 AM, Frankie Bagnardi wrote: It doesn't really need to clone anything, you just create a promise on each side, on top of the normal events. And how is the resolution value transferred over? This is the cloning step! -Boris ___

Re: Standardize ES Worker

My example is polyfillable and include cloning final result of promise. Actually it's RPC built above current worker messaging capabilities. That's so prevalent use case that I'm convinced it should be built in language. On 27 Oct 2016 3:57 p.m., "Boris Zbarsky" wrote: > On

Re: Standardize ES Worker

It doesn't really need to clone anything, you just create a promise on each side, on top of the normal events. The way you'd implement this currently is a token that gets passed to the worker with the request payload, and gets sent back with the response payload. It'd just be nice to save some

Re: Standardize ES Worker

On 10/27/16 9:48 AM, Michał Wadas wrote: Currently we put emphasis on request-response model - we request something from function (returning Promise/taking callback) and we wait for single return value. Workers are different beasts - they can emit messages on their own and don't have to emit ANY

Re: Standardize ES Worker

Resending, because I forgotten to include es-discuss mail. Anyway, can you explain it more about mismatch between WebWorker and modern > js idioms > Currently we put emphasis on request-response model - we request something from function (returning Promise/taking callback) and we wait for

Re: Standardize ES Worker

I originally thought such functionality can be implemented on top of current event based model, but request-response pattern is such commonly used for workers so it's worth to consider including this to spec. But the current event namespace already has it's own usage so how about something like

Re: Standardize ES Worker

I agree that we need additional modification from WebWorker spec. What I mean on the first post is that we (likely) can make standard Worker spec as a (mostly) subset of WebWorker spec so current codes using WebWorker need not to be changed. Anyway, can you explain it more about mismatch between

Re: Standardize ES Worker

Maybe with modification. I currently feel workers are a bit heavy (with their event driven nature), and they most definitely don't follow the idioms of the modern JavaScript language (very promise heavy). On Sun, Oct 23, 2016, 02:11 Park Hyeonu wrote: > Now we're about to

Standardize ES Worker

Now we're about to standardize thread-shared memory for EcmaScript( https://github.com/tc39/ecmascript_sharedmem). But how about the thread itself? For this topic, I don't think we should develop another thread spec for ES as we already have a nice one - WebWorker. This spec allows multithreading