[whatwg] Web Workers and MessagePort feedback

[Jonas Sicking]

Aaron Boodman wrote:
> I'm still digesting the Web Worker proposal, but here is some
> feedback. Sorry it is a bit long.
> 
> 
> Structural API stuff:
> 
> - I still haven't really internalized the need to either have workers
> speak directly to anyone other than the person who created them, or
> the other use cases that MessageChannels are intended for. There is a
> lot of complexity here. I think we need to add some requirements and
> motivations to the top of the doc, and some code samples showing the
> intended usage before implementors can really decide whether it's
> worth taking on.
> 
> - It seems like we might want an object that represents workers. This
> would allow us put the 'onload' and 'onerror' events from MessagePort
> there, instead of on MessagePort, which makes more sense to me (I
> don't know what it means for a MessagePort to 'load' or 'error'
> outside of the context of a worker). MessagePort.onunload could then
> change to 'onclose' to go with the close() method.
> 
> It seems like over time, we might want to be able to perform other
> operations on a worker and having the worker object might be handy.

Agreed.

> I know this is weird wrt GC when combined with MessagePorts, and I
> don't have a proposed solution.

I don't think we should say much regarding GC at all. All we should say 
is that GC should not affect the operation of the page. I.e. it is not 
allowed to GC an Worker that someone still has references to, or a 
Worker that has XHR loads in progress or timers pending.

Very few other specs mention GC and I haven't noticed that ever being a 
problem. For example everyone agrees that it's a bug that gecko 
sometimes GCs the parent of a node, if you're not actively holding any 
references to anything in the parent chain.

> - It's odd to me that the way to establish a channel to a worker
> depends on whether you are the creator of the worker or not. The
> creator gets a MessagePort to a new channel back from createWorker(),
> but any other function must pass a new MessagePort over the original
> one, and the worker must know to use that secondary port to talk back.
> 
> I would prefer to see something like:
> 
> void Worker.postMessage(DOMString message)
> void Worker.postMessage(DOMString message, MessagePort port)
> 
> That way the way to establish a new channel is the same for all
> callers. It also has the advantage of looking similar to a window's
> postMessage API.

Agreed.

> Here is how the previous two suggestions would look together:
> 
> var worker = new Worker("foo.js");
> worker.onload = function() { ... }
> worker.onerror = function() { ... }
> worker.onunload = function() { ... }  // called when the worker shuts down
> worker.sendMessage("hello!");

So I really like this API. However it makes it completely impossible to 
ever pass worker objects across threads. I.e. we could never allow:

worker1.postMessage("...", worker2);

This would be very strange if we had .onload, .onerror etc on the worker 
object itself since those properties wouldn't make much sense living in 
multiple "threads" at once.

While I agree direct communication between sibling workers is an 
edgecase, it's something I would prefer to not make impossible for 
future versions of the spec.

Though I just realized that we could cover that case using only 
MessagePorts. So we say that you can only communicate with your creator, 
and any children using direct .postMessage. If you want to more complex 
communication patterns then set up MessagePorts.

> - The spec says that as soon as a worker is not reachable (determined
> via GC) from any MessagePort, it is eligible for shutdown. Shutdown
> would attempt to finish all queued messages, but not allow any new
> ones.
> 
> This concerns me because it means that workers will have different
> behavior depending on GC timing. If a worker is not referenced from
> any port, and it sends an XHR, that XHR may or may not be sent
> depending on when GC runs. This is different than how XHR behaves
> normally. Typically, XHR objects that have outstanding IO but no
> referers will not be GC'd until they complete or fail.
> 
> Finally this does not allow use cases such as creating a worker to
> synchronize a local database with the network without ever sending
> notifications back to the parent.
> 
> Maybe workers should stay alive as long as any of the following are true:
> 
> - There is script running in them
> - There are messages to them queued
> - There is a messageport alive anywhere that could send messages to them
> - There are "asynchronous operations" (xhr, timers, database
> operations) inside them outstanding

Agreed. Like I said above, I think the less we say about GC the better. 
GC effects should not be noticeable to the page.

> - Why is there an ownerWindow property on MessagePort? If I understand
> correctly, this is just a synonym for the 'window' object of the
> currently executing script context.  I think it should go away.

If we put postMessage directly on the Worker object we don't need to 
mention MessagePorts in the Web workers spec at all. They can just be an 
orthogonal specs.

> - The purpose of 'import()' on WindowWorker was not immediately
> obvious to me from its name. Should it be 'importScript()'? or
> 'includeScript()' maybe?
> 
> - Should import() accept an array of URLs, so that the UA can fetch
> them in parallel if it has the ability to do that?

Agreed on both.

> - The string URL property on the WindowWorker interface is less useful
> than the parsed structure that window.location has. Can we use
> something like this instead, except making it read-only?

Why do we need it at all?

If we do think it's useful, most of the uses that I've seen for the 
parsed URL structure has been to set the .hash in order to scroll around 
on a page or communicate between iframes of different origins (ugh!!). 
Neither of these applies here I'd say.

> - The "front-line" nomenclature was a bit weird to me. How about "top-level"?

I didn't try to grokk this part yet. Is it just about estabilishing 
lifetime of the worker objects? If so, see my previous comments about GC.

> - Would it be too weird to have createWorker overloaded to take an
> optional name parameter? This would make the behavior similar to
> window.open(), which either opens a new window or reuses an existing
> window with the same name.

What would it be used for? window.open uses the name so you can target 
links at it which doesn't seem like it applies here either.

/ Jonas