- From: Alexey Proskuryakov <ap@webkit.org>
- Date: Fri, 14 Nov 2008 02:05:14 +0300
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
Received on Thursday, 13 November 2008 15:05:14 UTC