Standardize ES Worker

Frankie Bagnardi f.bagnardi at
Thu Oct 27 14:02:15 UTC 2016

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 work for a common use case, and require less
cooperation between the worker and main code.

On Thu, Oct 27, 2016 at 6:57 AM, Boris Zbarsky <bzbarsky at> wrote:

> 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 messages on completion.
> Right.  The point of workers in the web platform is to do computation in a
> separate context.  The computation need not be communicated back to the
> spawning page, because workers can do their own I/O.
> // main.js
>> const worker = new Worker('worker.js');
>> worker.request('ajaxCall', {url: ' <>'});
>> // return Promise resolving to Response object
>> worker.request('undefinedMethod'); // return rejected Promise
>> // worker.js
>> self.on('ajaxCall', (data)=>{ return Promise.resolve(new Response); });
> Workers in the web platform have a shared-nothing model.  The above
> example seems to assume that the Response and the Promise are either shared
> across the main script and the worker or auto-cloned at the boundary, right?
> -Boris
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list