[whatwg] Combining the DedicatedWorker and SharedWorker interfaces

[Jonas Sicking]

Alexey Proskuryakov wrote:
> 
> Nov 14, 2008, в 1:20 AM, Jonas Sicking написал(а):
> 
>>> If we don't make the above change, I think that we should remove
>>> startConversation(). It doesn't offer enough different functionality
>>> over passing a |new MessageChannel().port2| to be worth the extra API
>>> IMO.
>>
>> No, this is *exactly* the same functionality as passing |new 
>> MessageChannel().port2| through postMessage.
> 
> For the sake of completeness, a connect/startConversation method on a 
> worker really should automatically open the receiving port - this is 
> what examples posted so far implied, and it would cause a lot of 
> aggravation if it didn't. I know I'm often forgetting to open the port 
> when writing my tests, and it's not a very easy mistake to spot.

a port is automatically "opened" ('started' per spec) when you set the 
onmessage property or when you call .start() on it. This is required if 
we want to allow ports to be passed around several steps (i.e. to an 
worker inside an iframe inside an iframe) without having race conditions.

Note that this is unrelated to the workers spec as MessagePorts are 
defined in HTML5

>> At this point I have to ask what the problem you are trying to solve 
>> is? What is wrong with the current spec as is?
> 
> 
> Not speaking for Aaron, of course, but...
> 
> Besides API usability that we've already discussed back and forth 
> without reaching an agreement,

What are the API usability issues you have with the current API? It's 
the goals here that I think we need to agree on before we can have 
useful discussions around the proposals.

> I'm very much concerned about the current 
> spec being implementable in its current form. It has a lot of notions 
> and algorithms that are not correctly defined. For a randomly picked 
> example:
> 
> -----------------------------
> Each WorkerGlobalScope worker global scope has a list of the worker's 
> ports, which consists of all the MessagePort objects that are entangled 
> with another port and that have one (but only one) port owned by worker 
> global scope. This list includes all the MessagePort objects that are in 
> events pending in the queue of events, as well as the implicit 
> MessagePort in the case of dedicated workers.
> -----------------------------
> 
> In an async processing model, there is simply no way for the receiver to 
> have a list of all objects that were posted to it - it's exactly the 
> reason for the existence of the queue that events are delivered 
> asynchronously and cannot be peeked before being delivered. For example, 
> in a multi-process implementation, these events may still be across 
> process boundary.

Note that this list of ports is not exposed to any API. Honestly I'm not 
really sure why the spec says that you need a list at all, other than 
maybe to talk about GC (which i've many times mentioned I think the spec 
should not need to "define").

> Also (from HTML5):
> -----------------------------
> Each MessagePort object can be entangled with another (a symmetric 
> relationship).
> -----------------------------
> 
> It is not possible to have a symmetric relationship in an asynchronous 
> messaging model - we need a multi-step entagling/unentangling protocol, 
> so the relationship is necessarily asymmetric. One can't freeze another 
> process (or really, even another thread) to change something in it 
> synchronously.

Actually, the entanglement can be dealt with asyncronously, although 
it's a bit complicated and unperformant. This can be trivially changed 
though without making any changes to the API. I'll start a separate 
thread on that since this is not part of the workers spec.

> Some instances of implied synchronous thinking can be corrected rather 
> easily, but not all of them. So, I do not really see how anyone can 
> claim implementing the spec, or even a subset of it at this point.

Feel free to try our implementation of a subset of the spec ;)

It's available here and runs example 1.1.1 and 1.1.3 just fine.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

We're using separate threads for workers, not separate processes, but 
nothing we are doing couldn't be done across processes rather than 
across threads.

/ Jonas