[whatwg] Combining the DedicatedWorker and SharedWorker interfaces

[Alexey Proskuryakov]

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.

So, even though the current spec doesn't say this, there should be  
some difference in behavior.

> 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, 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.

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.

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.

- WBR, Alexey Proskuryakov