This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 15063 - each MessageChannel acts as its own task source. This means that messages sent using this function are not guaranteed to execute in order, since the order task sources are processed isn't specified.
Summary: each MessageChannel acts as its own task source. This means that messages se...
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
: 18033 (view as bug list)
Depends on:
Reported: 2011-12-05 16:42 UTC by contributor
Modified: 2013-01-29 20:59 UTC (History)
4 users (show)

See Also:


Description contributor 2011-12-05 16:42:09 UTC

each MessageChannel acts as its own task source.  This means that messages
sent using this function are not guaranteed to execute in order, since the
order task sources are processed isn't specified.

Posted from: by
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8) AppleWebKit/535.8 (KHTML, like Gecko) Chrome/17.0.942.0 Safari/535.8
Comment 1 Simon Pieters 2011-12-05 16:43:40 UTC
The above is quoted from

I think it's a problem. We shouldn't let the order be unspecified for ports within a single window (or worker).
Comment 2 Ian 'Hixie' Hickson 2011-12-07 23:38:56 UTC
Why is this a problem? Seems pretty reasonable to me. Implementations should be allowed to implement all message channels by routing messages through a central dispatch process, and if we do that there's no way to really make channels that happen to have both ports in one process magically be ordered relative to each other.
Comment 3 Simon Pieters 2011-12-08 09:34:39 UTC
Because people have used multiple MessageChannels as a way to implement "queue a task" polyfill (which they want to execute in order), and they do execute in order in Opera and Chrome today. If we change it to not execute in order, sites using such polyfills would break sometimes in hard-to-debug ways.
Comment 4 Ian 'Hixie' Hickson 2011-12-09 00:29:12 UTC
I am highly skeptical that the order is actually guaranteed in Chrome today, especially around the time if and while one were to send the port across processes and back.
Comment 5 Simon Pieters 2011-12-09 12:19:54 UTC
The polyfills don't send the ports to other processes, though. When a port is sent to somewhere else (and possibly back again), I'm fine with order being arbitrary.
Comment 6 Ian 'Hixie' Hickson 2011-12-09 23:06:38 UTC
Hmmm... So you're saying the order should be defined only amongst ports that have been created by a MessageChannel and not yet ever been sent over another channel...

I guess we can do that, though it'll be really convoluted to spec...
Comment 7 contributor 2012-07-18 16:01:39 UTC
This bug was cloned to create bug 18033 as part of operation convergence.
Comment 8 Ian 'Hixie' Hickson 2012-07-27 06:00:36 UTC
If there's any way to get out of speccing this, I'd love to take it...
Comment 9 James Graham 2012-08-13 12:22:03 UTC
I think I agree with Simon here; there will be compat constraints on message ordering.

I wonder if it is OK to make a design that assumes order can be preserved for each unit of related browsing context. Then each unit of related browsing context could have two associated task queues; one for same-unit messages and one for different-unit messages. Messages from the two queues might interleave, and messages from the other-unit queue might not have a well-defined order, but messages from the same-unit queue would.

Basically this is equivalent to the "central dispatch server" design, but with a spec-mandated optimisation that as long as you are not going outside your own related browsing context neighborhood you don't go through the seperate server but instead straight into a local queue.
Comment 10 Ian 'Hixie' Hickson 2012-10-10 23:52:37 UTC
That's more or less what I had in mind earlier when I said it'd be convoluted to spec (and probably implement). But I think there's a simpler solution:

How about we just make each port have a flag that tracks if it or its paired port have ever gone through another port. While that flag isn't set (i.e. both ports are still in the same unit of related browsing contexts (henceforth "unit") as the original message channel), then you use a unit-global task source shared with all the other MessagePort objects with the flag set in the same unit. But if you ever send a port through another port, then both the sent port and its paired port, as well as the new port on the other end when the port comes out, have the flag set, and then they start using their own task source just for themselves.
Comment 11 Simon Pieters 2012-10-11 06:53:53 UTC
That sounds OK.
Comment 12 Ian 'Hixie' Hickson 2012-10-19 22:27:20 UTC
*** Bug 18033 has been marked as a duplicate of this bug. ***
Comment 13 contributor 2013-01-29 20:59:21 UTC
Checked in as WHATWG revision r7669.
Check-in comment: Make MessagePort objects synchronised until they are posted through another port.