[whatwg] Combining the DedicatedWorker and SharedWorker interfaces

[Alexey Proskuryakov]

Nov 14, 2008, в 3:59 AM, Ian Hickson написал(а):

>> 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.
>
> What do you mean by "open the port"? Do you mean calling start()? If  
> so,
> that should happen automatically when you set onmessage the first  
> time,
> per spec.


Oh, that's my mistake - I totally didn't expect that it could have  
such side effect. It seems weird that addEventListener("message", ...)  
does not have such effect, does it?

>> 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.
>
> It actually doesn't really matter if there is something that has been
> posted but not yet received, because that is indistinguishable (as  
> far as
> I can tell) from the case of the worker having shut down a split  
> second
> before that object was posted.

I'm not sure what state you mean by "shut down" here - the spec does  
not define this, and shutting down a side of an async communication  
channel is complicated (see e.g. a TCP/IP state diagram). Anyway, the  
contents of "the worker's ports" is used for defining "active needed  
worker" and "suspendable worker" further on, which are concepts that  
are very important for worker lifetime definition. If the ports in  
event queue are not important, then the spec should not say that they  
are included in "the worker's ports". This would resolve the  
concurrency problem, but I don't think that the resulting behavior  
would be desirable.

>> 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.
>
> The above is not a requirement, it's just a description of the  
> concept. I
> don't think anything actually depends on it being symmetric; all the  
> parts
> that actually entangle ports have (or, are intended to have, maybe I
> missed some) pretty well-defined synchronisation points.

OK, say there is a pair of entangled ports in different threads/ 
processes, portA and portB. We concurrently post both with  
postMessage, which causes the ports to be cloned. From the point of  
view of first thread, PortA is now unentangled, and portA' is  
entangled with portB. From the point of view of second thread, PortB  
is unentangled, and portB' is entangled with portA.

Next, threads send asynchronous notifications to each other, asking to  
update entangling information. First thread's notification asks portB  
to become entangled with portA'. So, portB will need to forward this  
notification to portB' (and possibly further, because portB' may have  
been posted and cloned again). This already is unduly complicated.

Now consider that all these ports need to have destroyed sooner or  
later, but not too soon. This basically means that we now have a many- 
to-many distributed GC system. It was bad enough when we had to  
garbage protect ports between threads, because this required  
modification of the JavaScript interpreter to support a certain case  
of distributed GC. But this example basically shows that we need a  
full-blown distributed GC system in order to implement port cloning.

> For example, any method that entangles two ports blocks until both  
> threads are synchronised
> and entangled.

This will cause deadlocks - if portB' is sent to the first thread as  
portB'' in the above scheme, the lock will not let synchronization  
ever finish.

> (The spec is somewhat implicit about this, but the intent is that  
> workers
> really be implemented either as two system threads, one doing
> communication and one running the JS, or by one system thread that  
> runs
> the JS in an interruptible fashion. In particular, doing something  
> that
> synchronises with a worker isn't expected to have to wait for that  
> worker
> to finish running its current JS.)

The JS thread will need to be interrupted in any case - we certainly  
don't want it to read a half-written pointer from memory or something.  
Adding memory barriers around access to data that can be modified  
externally is not sufficient, because MessagePort algorithms are not  
designed in a lock-free fashion (lock-free algorithms that only rely  
on read/write atomicity do exist, but these aren't such). Locking  
around all MessagePort functions will cause deadlocks, as demonstrated  
above, and is generally against best practices. A middle ground may  
exist, but it may not, and it's definitely hard to find.

I don't think that pursuing a design that relies on locking is  
particularly promising - for the same reason that workers do not  
expose shared data to JS programmers, it is highly desirable to not  
rely on shared data in implementations, too (except for a few well  
understood constructs, such as an event queue). So, I think that the  
specs (Web Workers and HTML5 channel messaging) should be cleaned up  
from anything that mentions synchronous access to entangled port's  
data structures to really be verified for correctness. This is not  
straightforward, and may seriously affect the API - e.g., I doubt that  
passing MessagePorts around is implementable with reasonable  
complexity, and there is not a lot of use in MessagePorts if they  
cannot be passed around.

- WBR, Alexey Proskuryakov