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
