Standardize ES Worker
isiahmeadows at gmail.com
Mon Oct 31 18:47:14 UTC 2016
On Mon, Oct 31, 2016, 10:33 Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 10/31/16 8:42 AM, Isiah Meadows wrote:
> > When the worker has finished loading, so you can send and receive
> 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 infinite loop)?
You still add the `onMessage` handler then. The promise is to encapsulate
errors that occur when creating the worker (e.g. the file doesn't exist).
To clarify, the messages sent since the last tick, and returned promises
resolved, are queued after the current tick ends.
Also, both exports from the worker's side are optional.
> Or is the idea to not support this behavior? If so, I'm a little
> worried about specifying something with totally different behavior from
> DOM Workers and calling it "Worker".
It's supported. See above.
> > What if the "result" of the message is a sequence of messages back?
> > This is a common thing to do with web workers: ask it to do
> > and it sends the answer back in chunks.
> > The result is the value returned from the worker's `onMessage`. This
> > does permit async return values, because it's fairly common (at least in
> > my case) to send a message and expect a response as effectively a return
> > value, and I would like to reify that.
> I think we're talking past each other a bit here, but please see above
> about naming.
Yeah...I don't think we were on the same page.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss