Ian Hickson wrote:
On Fri, 8 Aug 2008, Jonas Sicking wrote:
(We might want to add an onconnect property to WorkerGlobalScope,
but it doesn't seem strictly needed)
How else would you connect to a shared worker?
That is done at an application level. For example:
worker = createSharedWorker("foo", "bar.js");
worker.addEventListener("message", handler, false);
worker.postMessage("wassup dude, i just connected");
How would the worker distinguish that from the original "parent" sending
the same message?
Why would the original parent same the message twice? Of course
applications following their own application level protocols is going to
break themselves.
Actually, it seems like onconnect as defined in the current spec has a
race condition. The shared worker example does the following:
var worker = createSharedWorker('worker.js', 'core');
function configure(event) {
if (event.message.substr(0, 4) != 'cfg ') return;
var name = event.message.substr(4).split(' ', 1);
// update display to mention our name is name
document.getElementsByTagName('h1')[0].textContent += ' ' + name;
// no longer need this listener
worker.port.removeEventListener('message', configure, false);
}
worker.port.addEventListener('message', configure, false);
However what's to say that the 'connect' event hasn't fired inside the
worker before the 'worker.port.addEventListener' line executes?
Doesn't matter. MessagePorts queue up messages until they receiver either
sets onmessage or calls start(). (This is explained just below the
example.)
Note that there can already be other listeners to the port, so the port
has been activated.
The port only activates if you set onmessage or call start(). Calling
addEventListener() doesn't activate it.
Ah, i missed the fact that calling createSheredWorker always created a
new Worker object, even if one already existed.
/ Jonas
