Standardize ES Worker

Michał Wadas michalwadas at gmail.com
Thu Oct 27 16:25:58 UTC 2016


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" <bzbarsky at mit.edu> 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: 'example.com <http://example.com>'});
>> // 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 mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161027/1635adb2/attachment.html>


More information about the es-discuss mailing list