I'm trying to use SharedWorkers, but not getting anywhere. I whipped up a quick demoscript where a page "ping"s a SharedWorker and the SharedWorker should "pong" back, but something isnt working, and I have no idea what. The code is running at http://rektide.voodoowarez.com/2010/2/ping.html . Its also pasted below:
First off, I'm really happy to see developers starting to use SharedWorkers! I'm sorry you ran into problems, but the debugger support for SharedWorkers is still a work in progress.
Anyhow, there are several issues, most of which are fairly non-obvious/obscure, so don't feel bad for stubbing your toe on them - I've run into every single one of these myself at one time or another:
1) Your onconnect handler in pong.js has a typo:
event.ports[0].postMess*aa*ge("connect")
Note the double "a" in postMessaage(). It turns out that parse exceptions generated within workers are not always logged to the developers console, which makes errors like this really hard to track down. I've logged bug http://code.google.com/p/chromium/issues/detail?id=36577 to track this issue.
2) The messageHandler function won't work, because MessageEvent won't have event.ports[0] set.
MessageEvent has its "ports" attribute set to the set of ports that were passed to postMessage() ( http://www.w3.org/TR/html5/comms.html#dom-messageevent-ports). You are expecting it to be set to the port that sent the message, which isn't the case. The onmessage handler is not passed a reference to the entangled port - what you need to do is keep a reference around to the source port sent to you in the onconnect handler. The way I usually do this is via a closure:
var messageHandler = function(event, port) { port.postMessage("pong")
3) A MessagePort will not deliver onmessage events until you call start() on it. So if you just use addEventListener("message", function...), your function won't be called until you call port.start(). If you register an event listener by setting the onmessage attribute directly, then it starts the port for you. Yes, it's very confusing ( http://www.w3.org/TR/html5/comms.html#messageport) but the intent is to make sure that ports don't dispatch events until the listener has been added. I never use addEventListener() for exactly this reason but instead directly set the onmessage attribute.
On Mon, Feb 22, 2010 at 8:34 PM, rektide <rekt...@voodoowarez.com> wrote: > I'm trying to use SharedWorkers, but not getting anywhere. I whipped > up a quick demoscript where a page "ping"s a SharedWorker and the > SharedWorker should "pong" back, but something isnt working, and I > have no idea what. The code is running at > http://rektide.voodoowarez.com/2010/2/ping.html > . Its also pasted below:
> Please help me use this incredible feature. I have no idea what I'm > doing wrong. > -rektide
> -- > You received this message because you are subscribed to the Google Groups > "Chromium HTML5" group. > To post to this group, send email to chromium-ht...@chromium.org. > To unsubscribe from this group, send email to > chromium-html5+unsubscr...@chromium.org<chromium-html5%2Bunsubscr...@chromium.org> > . > For more options, visit this group at > http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.
On Tue, Feb 23, 2010 at 11:12 AM, Drew Wilson <atwil...@chromium.org> wrote: > First off, I'm really happy to see developers starting to use > SharedWorkers! I'm sorry you ran into problems, but the debugger support for > SharedWorkers is still a work in progress.
> Anyhow, there are several issues, most of which are fairly > non-obvious/obscure, so don't feel bad for stubbing your toe on them - I've > run into every single one of these myself at one time or another:
> 1) Your onconnect handler in pong.js has a typo:
> event.ports[0].postMess*aa*ge("connect")
> Note the double "a" in postMessaage(). It turns out that parse exceptions > generated within workers are not always logged to the developers console, > which makes errors like this really hard to track down. I've logged bug > http://code.google.com/p/chromium/issues/detail?id=36577 to track this > issue.
> 2) The messageHandler function won't work, because MessageEvent won't have > event.ports[0] set.
> MessageEvent has its "ports" attribute set to the set of ports that were > passed to postMessage() ( > http://www.w3.org/TR/html5/comms.html#dom-messageevent-ports). You are > expecting it to be set to the port that sent the message, which isn't the > case. The onmessage handler is not passed a reference to the entangled port > - what you need to do is keep a reference around to the source port sent to > you in the onconnect handler. The way I usually do this is via a closure:
> 3) A MessagePort will not deliver onmessage events until you call start() > on it. So if you just use addEventListener("message", function...), your > function won't be called until you call port.start(). If you register an > event listener by setting the onmessage attribute directly, then it starts > the port for you. Yes, it's very confusing ( > http://www.w3.org/TR/html5/comms.html#messageport) but the intent is to > make sure that ports don't dispatch events until the listener has been > added. I never use addEventListener() for exactly this reason but instead > directly set the onmessage attribute.
> On Mon, Feb 22, 2010 at 8:34 PM, rektide <rekt...@voodoowarez.com> wrote:
>> I'm trying to use SharedWorkers, but not getting anywhere. I whipped >> up a quick demoscript where a page "ping"s a SharedWorker and the >> SharedWorker should "pong" back, but something isnt working, and I >> have no idea what. The code is running at >> http://rektide.voodoowarez.com/2010/2/ping.html >> . Its also pasted below:
>> Please help me use this incredible feature. I have no idea what I'm >> doing wrong. >> -rektide
>> -- >> You received this message because you are subscribed to the Google Groups >> "Chromium HTML5" group. >> To post to this group, send email to chromium-ht...@chromium.org. >> To unsubscribe from this group, send email to >> chromium-html5+unsubscr...@chromium.org<chromium-html5%2Bunsubscr...@chromium.org> >> . >> For more options, visit this group at >> http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.
I tried your example in some older build of Chromium I had installed (around 39330) and it was working nicely. However, the example from Simon Peters on the WHATWG mailing list [1] was crashing - Chromium showed an exception that a HTML SharedWorker crashed (in the yellow notification bar below the bookmarks bar, nothing was alerted in the console). That example differs from this one in basically one thing - the shared worker is instantiated in two places (in a window context and in a child iframe context). Notice, however, that the workers are not given a name in Simon's example. Anyway - the Chromium version I had installed crashed when a SharedWorker was created in both contexts from the same JavaScript source, but worked fine when created in only one context (no matter which one).
Hoping that it was a bug which had been resolved in never versions, I did an update of Chromium and am now running 40217. However, now I can't even get your example running (which, as I said, worked in the older version). No exceptions are thrown, but from what I can tell - Chromium breaks when instantiating a SharedWorker. Did anything SharedWorker-wise change in the last ~800 versions that would cause the example to stop working? Possibly helpful debugging info: windows xp OS and I'm running the example from the local filesystem, they're not online. Any ideas? :)
I think Workers and SharedWorkers are awesome and can't wait to see all the cool things people will be doing with them. That's one reason why I developed the pmrpc library [2] which is essentially a RPC mechanism built on top of cross-document messaging APIs (for inter- window/iframe communication) and web workers (for communication between workers and windows/iframes). The library currently supports regular Workers but has been waiting on a full SharedWorker implementation in Chromium so I can test, debug and rejoice :).
> On Tue, Feb 23, 2010 at 11:12 AM, Drew Wilson <atwil...@chromium.org> wrote: > > First off, I'm really happy to see developers starting to use > > SharedWorkers! I'm sorry you ran into problems, but the debugger support for > > SharedWorkers is still a work in progress.
> > Anyhow, there are several issues, most of which are fairly > > non-obvious/obscure, so don't feel bad for stubbing your toe on them - I've > > run into every single one of these myself at one time or another:
> > 1) Your onconnect handler in pong.js has a typo:
> > event.ports[0].postMess*aa*ge("connect")
> > Note the double "a" in postMessaage(). It turns out that parse exceptions > > generated within workers are not always logged to the developers console, > > which makes errors like this really hard to track down. I've logged bug > >http://code.google.com/p/chromium/issues/detail?id=36577to track this > > issue.
> > 2) The messageHandler function won't work, because MessageEvent won't have > > event.ports[0] set.
> > MessageEvent has its "ports" attribute set to the set of ports that were > > passed to postMessage() ( > >http://www.w3.org/TR/html5/comms.html#dom-messageevent-ports). You are > > expecting it to be set to the port that sent the message, which isn't the > > case. The onmessage handler is not passed a reference to the entangled port > > - what you need to do is keep a reference around to the source port sent to > > you in the onconnect handler. The way I usually do this is via a closure:
> > 3) A MessagePort will not deliver onmessage events until you call start() > > on it. So if you just use addEventListener("message", function...), your > > function won't be called until you call port.start(). If you register an > > event listener by setting the onmessage attribute directly, then it starts > > the port for you. Yes, it's very confusing ( > >http://www.w3.org/TR/html5/comms.html#messageport) but the intent is to > > make sure that ports don't dispatch events until the listener has been > > added. I never use addEventListener() for exactly this reason but instead > > directly set the onmessage attribute.
> > On Mon, Feb 22, 2010 at 8:34 PM, rektide <rekt...@voodoowarez.com> wrote:
> >> I'm trying to use SharedWorkers, but not getting anywhere. I whipped > >> up a quick demoscript where a page "ping"s a SharedWorker and the > >> SharedWorker should "pong" back, but something isnt working, and I > >> have no idea what. The code is running at > >>http://rektide.voodoowarez.com/2010/2/ping.html > >> . Its also pasted below:
> >> Please help me use this incredible feature. I have no idea what I'm > >> doing wrong. > >> -rektide
> >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Chromium HTML5" group. > >> To post to this group, send email to chromium-ht...@chromium.org. > >> To unsubscribe from this group, send email to > >> chromium-html5+unsubscr...@chromium.org<chromium-html5%2Bunsubscr...@chromium.org> > >> . > >> For more options, visit this group at > >>http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.
On Sat, Feb 27, 2010 at 17:59, Nico Weber <tha...@google.com> wrote: > There was a recent change that disallows local html files to access other > local files. That might be the cause. Check the googlechromereleasenotes > blog for a flag that gives you the old behavior.
> Nico
> On Feb 27, 2010 8:28 AM, "Ivan Zuzak" <izu...@gmail.com> wrote:
> Hi Drew,
> I tried your example in some older build of Chromium I had installed > (around 39330) and it was working nicely. However, the example from > Simon Peters on the WHATWG mailing list [1] was crashing - Chromium > showed an exception that a HTML SharedWorker crashed (in the yellow > notification bar below the bookmarks bar, nothing was alerted in the > console). That example differs from this one in basically one thing - > the shared worker is instantiated in two places (in a window context > and in a child iframe context). Notice, however, that the workers are > not given a name in Simon's example. Anyway - the Chromium version I > had installed crashed when a SharedWorker was created in both contexts > from the same JavaScript source, but worked fine when created in only > one context (no matter which one).
> Hoping that it was a bug which had been resolved in never versions, I > did an update of Chromium and am now running 40217. However, now I > can't even get your example running (which, as I said, worked in the > older version). No exceptions are thrown, but from what I can tell - > Chromium breaks when instantiating a SharedWorker. Did anything > SharedWorker-wise change in the last ~800 versions that would cause > the example to stop working? Possibly helpful debugging info: windows > xp OS and I'm running the example from the local filesystem, they're > not online. Any ideas? :)
> I think Workers and SharedWorkers are awesome and can't wait to see > all the cool things people will be doing with them. That's one reason > why I developed the pmrpc library [2] which is essentially a RPC > mechanism built on top of cross-document messaging APIs (for inter- > window/iframe communication) and web workers (for communication > between workers and windows/iframes). The library currently supports > regular Workers but has been waiting on a full SharedWorker > implementation in Chromium so I can test, debug and rejoice :).
On Sat, Feb 27, 2010 at 3:50 AM, Ivan Zuzak <izu...@gmail.com> wrote: > Hi Drew,
> I tried your example in some older build of Chromium I had installed > (around 39330) and it was working nicely. However, the example from > Simon Peters on the WHATWG mailing list [1] was crashing - Chromium > showed an exception that a HTML SharedWorker crashed (in the yellow > notification bar below the bookmarks bar, nothing was alerted in the > console). That example differs from this one in basically one thing - > the shared worker is instantiated in two places (in a window context > and in a child iframe context). Notice, however, that the workers are > not given a name in Simon's example. Anyway - the Chromium version I > had installed crashed when a SharedWorker was created in both contexts > from the same JavaScript source, but worked fine when created in only > one context (no matter which one).
> Hoping that it was a bug which had been resolved in never versions, I > did an update of Chromium and am now running 40217. However, now I > can't even get your example running (which, as I said, worked in the > older version). No exceptions are thrown, but from what I can tell - > Chromium breaks when instantiating a SharedWorker. Did anything > SharedWorker-wise change in the last ~800 versions that would cause > the example to stop working? Possibly helpful debugging info: windows > xp OS and I'm running the example from the local filesystem, they're > not online. Any ideas? :)
> I think Workers and SharedWorkers are awesome and can't wait to see > all the cool things people will be doing with them. That's one reason > why I developed the pmrpc library [2] which is essentially a RPC > mechanism built on top of cross-document messaging APIs (for inter- > window/iframe communication) and web workers (for communication > between workers and windows/iframes). The library currently supports > regular Workers but has been waiting on a full SharedWorker > implementation in Chromium so I can test, debug and rejoice :).
> On Feb 23, 10:27 pm, Drew Wilson <atwil...@chromium.org> wrote: > > Following up on this - for #2, I believe that MessageEvent.target == the > > port. So your messageHandler() function could be:
> > On Tue, Feb 23, 2010 at 11:12 AM, Drew Wilson <atwil...@chromium.org> > wrote: > > > First off, I'm really happy to see developers starting to use > > > SharedWorkers! I'm sorry you ran into problems, but the debugger > support for > > > SharedWorkers is still a work in progress.
> > > Anyhow, there are several issues, most of which are fairly > > > non-obvious/obscure, so don't feel bad for stubbing your toe on them - > I've > > > run into every single one of these myself at one time or another:
> > > 1) Your onconnect handler in pong.js has a typo:
> > > event.ports[0].postMess*aa*ge("connect")
> > > Note the double "a" in postMessaage(). It turns out that parse > exceptions > > > generated within workers are not always logged to the developers > console, > > > which makes errors like this really hard to track down. I've logged bug > > >http://code.google.com/p/chromium/issues/detail?id=36577to track this > > > issue.
> > > 2) The messageHandler function won't work, because MessageEvent won't > have > > > event.ports[0] set.
> > > MessageEvent has its "ports" attribute set to the set of ports that > were > > > passed to postMessage() ( > > >http://www.w3.org/TR/html5/comms.html#dom-messageevent-ports). You are > > > expecting it to be set to the port that sent the message, which isn't > the > > > case. The onmessage handler is not passed a reference to the entangled > port > > > - what you need to do is keep a reference around to the source port > sent to > > > you in the onconnect handler. The way I usually do this is via a > closure:
> > > 3) A MessagePort will not deliver onmessage events until you call > start() > > > on it. So if you just use addEventListener("message", function...), > your > > > function won't be called until you call port.start(). If you register > an > > > event listener by setting the onmessage attribute directly, then it > starts > > > the port for you. Yes, it's very confusing ( > > >http://www.w3.org/TR/html5/comms.html#messageport) but the intent is to > > > make sure that ports don't dispatch events until the listener has been > > > added. I never use addEventListener() for exactly this reason but > instead > > > directly set the onmessage attribute.
> > > On Mon, Feb 22, 2010 at 8:34 PM, rektide <rekt...@voodoowarez.com> > wrote:
> > >> I'm trying to use SharedWorkers, but not getting anywhere. I whipped > > >> up a quick demoscript where a page "ping"s a SharedWorker and the > > >> SharedWorker should "pong" back, but something isnt working, and I > > >> have no idea what. The code is running at > > >>http://rektide.voodoowarez.com/2010/2/ping.html > > >> . Its also pasted below:
> > >> Please help me use this incredible feature. I have no idea what I'm > > >> doing wrong. > > >> -rektide
> > >> -- > > >> You received this message because you are subscribed to the Google > Groups > > >> "Chromium HTML5" group. > > >> To post to this group, send email to chromium-ht...@chromium.org. > > >> To unsubscribe from this group, send email to > > >> chromium-html5+unsubscr...@chromium.org<chromium-html5%2Bunsubscr...@chromium.org> > <chromium-html5%2Bunsubscr...@chromium.org<chromium-html5%252Bunsubscr...@chromium.org>
> -- > You received this message because you are subscribed to the Google Groups > "Chromium HTML5" group. > To post to this group, send email to chromium-ht...@chromium.org. > To unsubscribe from this group, send email to > chromium-html5+unsubscr...@chromium.org<chromium-html5%2Bunsubscr...@chromium.org> > . > For more options, visit this group at > http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.
Drew - Simon's test case is working for me now (after updating Chromium to the latest version and starting with --allow-file-access-from-files as Nico suggested). Don't know why it was crashing in the old version. (Wrote the same on the html5 chromium mailing list, looks like you got dropped from the CC).
Thanks anyway! Now I'm cheering for supporting logging of worker exceptions in the console :). Ivan
On Mon, Mar 1, 2010 at 07:28, Drew Wilson <atwil...@chromium.org> wrote: > Thanks, Ivan - I'll give Simon's test case a shot tomorrow, since it sounds > like something bad is happening there (the crash). > -atw > On Sat, Feb 27, 2010 at 3:50 AM, Ivan Zuzak <izu...@gmail.com> wrote:
>> Hi Drew,
>> I tried your example in some older build of Chromium I had installed >> (around 39330) and it was working nicely. However, the example from >> Simon Peters on the WHATWG mailing list [1] was crashing - Chromium >> showed an exception that a HTML SharedWorker crashed (in the yellow >> notification bar below the bookmarks bar, nothing was alerted in the >> console). That example differs from this one in basically one thing - >> the shared worker is instantiated in two places (in a window context >> and in a child iframe context). Notice, however, that the workers are >> not given a name in Simon's example. Anyway - the Chromium version I >> had installed crashed when a SharedWorker was created in both contexts >> from the same JavaScript source, but worked fine when created in only >> one context (no matter which one).
>> Hoping that it was a bug which had been resolved in never versions, I >> did an update of Chromium and am now running 40217. However, now I >> can't even get your example running (which, as I said, worked in the >> older version). No exceptions are thrown, but from what I can tell - >> Chromium breaks when instantiating a SharedWorker. Did anything >> SharedWorker-wise change in the last ~800 versions that would cause >> the example to stop working? Possibly helpful debugging info: windows >> xp OS and I'm running the example from the local filesystem, they're >> not online. Any ideas? :)
>> I think Workers and SharedWorkers are awesome and can't wait to see >> all the cool things people will be doing with them. That's one reason >> why I developed the pmrpc library [2] which is essentially a RPC >> mechanism built on top of cross-document messaging APIs (for inter- >> window/iframe communication) and web workers (for communication >> between workers and windows/iframes). The library currently supports >> regular Workers but has been waiting on a full SharedWorker >> implementation in Chromium so I can test, debug and rejoice :).
>> On Feb 23, 10:27 pm, Drew Wilson <atwil...@chromium.org> wrote: >> > Following up on this - for #2, I believe that MessageEvent.target == the >> > port. So your messageHandler() function could be:
>> > On Tue, Feb 23, 2010 at 11:12 AM, Drew Wilson <atwil...@chromium.org> >> > wrote: >> > > First off, I'm really happy to see developers starting to use >> > > SharedWorkers! I'm sorry you ran into problems, but the debugger >> > > support for >> > > SharedWorkers is still a work in progress.
>> > > Anyhow, there are several issues, most of which are fairly >> > > non-obvious/obscure, so don't feel bad for stubbing your toe on them - >> > > I've >> > > run into every single one of these myself at one time or another:
>> > > 1) Your onconnect handler in pong.js has a typo:
>> > > event.ports[0].postMess*aa*ge("connect")
>> > > Note the double "a" in postMessaage(). It turns out that parse >> > > exceptions >> > > generated within workers are not always logged to the developers >> > > console, >> > > which makes errors like this really hard to track down. I've logged >> > > bug >> > >http://code.google.com/p/chromium/issues/detail?id=36577to track this >> > > issue.
>> > > 2) The messageHandler function won't work, because MessageEvent won't >> > > have >> > > event.ports[0] set.
>> > > MessageEvent has its "ports" attribute set to the set of ports that >> > > were >> > > passed to postMessage() ( >> > >http://www.w3.org/TR/html5/comms.html#dom-messageevent-ports). You are >> > > expecting it to be set to the port that sent the message, which isn't >> > > the >> > > case. The onmessage handler is not passed a reference to the entangled >> > > port >> > > - what you need to do is keep a reference around to the source port >> > > sent to >> > > you in the onconnect handler. The way I usually do this is via a >> > > closure:
>> > > 3) A MessagePort will not deliver onmessage events until you call >> > > start() >> > > on it. So if you just use addEventListener("message", function...), >> > > your >> > > function won't be called until you call port.start(). If you register >> > > an >> > > event listener by setting the onmessage attribute directly, then it >> > > starts >> > > the port for you. Yes, it's very confusing ( >> > >http://www.w3.org/TR/html5/comms.html#messageport) but the intent is to >> > > make sure that ports don't dispatch events until the listener has been >> > > added. I never use addEventListener() for exactly this reason but >> > > instead >> > > directly set the onmessage attribute.
>> > > On Mon, Feb 22, 2010 at 8:34 PM, rektide <rekt...@voodoowarez.com> >> > > wrote:
>> > >> I'm trying to use SharedWorkers, but not getting anywhere. I whipped >> > >> up a quick demoscript where a page "ping"s a SharedWorker and the >> > >> SharedWorker should "pong" back, but something isnt working, and I >> > >> have no idea what. The code is running at >> > >>http://rektide.voodoowarez.com/2010/2/ping.html >> > >> . Its also pasted below:
>> > >> Please help me use this incredible feature. I have no idea what I'm >> > >> doing wrong. >> > >> -rektide
>> > >> -- >> > >> You received this message because you are subscribed to the Google >> > >> Groups >> > >> "Chromium HTML5" group. >> > >> To post to this group, send email to chromium-ht...@chromium.org. >> > >> To unsubscribe from this group, send email to
>> -- >> You received this message because you are subscribed to the Google Groups >> "Chromium HTML5" group. >> To post to this group, send email to chromium-ht...@chromium.org. >> To unsubscribe from this group, send email to >> chromium-html5+unsubscr...@chromium.org. >> For more options, visit this group at >> http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.
I've been able to reproduce this crash using the Mac dev channel build (5.0.335.0), sporadically (it often takes several reloads to make it happen). It only seems to happen with the iframe test, which is interesting.
On Sun, Feb 28, 2010 at 11:10 PM, Ivan Žužak <izu...@gmail.com> wrote: > Drew - Simon's test case is working for me now (after updating > Chromium to the latest version and starting with > --allow-file-access-from-files as Nico suggested). Don't know why it > was crashing in the old version. (Wrote the same on the html5 chromium > mailing list, looks like you got dropped from the CC).
> Thanks anyway! Now I'm cheering for supporting logging of worker > exceptions in the console :). > Ivan
> On Mon, Mar 1, 2010 at 07:28, Drew Wilson <atwil...@chromium.org> wrote: > > Thanks, Ivan - I'll give Simon's test case a shot tomorrow, since it > sounds > > like something bad is happening there (the crash). > > -atw > > On Sat, Feb 27, 2010 at 3:50 AM, Ivan Zuzak <izu...@gmail.com> wrote:
> >> Hi Drew,
> >> I tried your example in some older build of Chromium I had installed > >> (around 39330) and it was working nicely. However, the example from > >> Simon Peters on the WHATWG mailing list [1] was crashing - Chromium > >> showed an exception that a HTML SharedWorker crashed (in the yellow > >> notification bar below the bookmarks bar, nothing was alerted in the > >> console). That example differs from this one in basically one thing - > >> the shared worker is instantiated in two places (in a window context > >> and in a child iframe context). Notice, however, that the workers are > >> not given a name in Simon's example. Anyway - the Chromium version I > >> had installed crashed when a SharedWorker was created in both contexts > >> from the same JavaScript source, but worked fine when created in only > >> one context (no matter which one).
> >> Hoping that it was a bug which had been resolved in never versions, I > >> did an update of Chromium and am now running 40217. However, now I > >> can't even get your example running (which, as I said, worked in the > >> older version). No exceptions are thrown, but from what I can tell - > >> Chromium breaks when instantiating a SharedWorker. Did anything > >> SharedWorker-wise change in the last ~800 versions that would cause > >> the example to stop working? Possibly helpful debugging info: windows > >> xp OS and I'm running the example from the local filesystem, they're > >> not online. Any ideas? :)
> >> I think Workers and SharedWorkers are awesome and can't wait to see > >> all the cool things people will be doing with them. That's one reason > >> why I developed the pmrpc library [2] which is essentially a RPC > >> mechanism built on top of cross-document messaging APIs (for inter- > >> window/iframe communication) and web workers (for communication > >> between workers and windows/iframes). The library currently supports > >> regular Workers but has been waiting on a full SharedWorker > >> implementation in Chromium so I can test, debug and rejoice :).
> >> On Feb 23, 10:27 pm, Drew Wilson <atwil...@chromium.org> wrote: > >> > Following up on this - for #2, I believe that MessageEvent.target == > the > >> > port. So your messageHandler() function could be:
> >> > On Tue, Feb 23, 2010 at 11:12 AM, Drew Wilson <atwil...@chromium.org> > >> > wrote: > >> > > First off, I'm really happy to see developers starting to use > >> > > SharedWorkers! I'm sorry you ran into problems, but the debugger > >> > > support for > >> > > SharedWorkers is still a work in progress.
> >> > > Anyhow, there are several issues, most of which are fairly > >> > > non-obvious/obscure, so don't feel bad for stubbing your toe on them > - > >> > > I've > >> > > run into every single one of these myself at one time or another:
> >> > > 1) Your onconnect handler in pong.js has a typo:
> >> > > event.ports[0].postMess*aa*ge("connect")
> >> > > Note the double "a" in postMessaage(). It turns out that parse > >> > > exceptions > >> > > generated within workers are not always logged to the developers > >> > > console, > >> > > which makes errors like this really hard to track down. I've logged > >> > > bug > >> > >http://code.google.com/p/chromium/issues/detail?id=36577to track > this > >> > > issue.
> >> > > 2) The messageHandler function won't work, because MessageEvent > won't > >> > > have > >> > > event.ports[0] set.
> >> > > MessageEvent has its "ports" attribute set to the set of ports that > >> > > were > >> > > passed to postMessage() ( > >> > >http://www.w3.org/TR/html5/comms.html#dom-messageevent-ports). You > are > >> > > expecting it to be set to the port that sent the message, which > isn't > >> > > the > >> > > case. The onmessage handler is not passed a reference to the > entangled > >> > > port > >> > > - what you need to do is keep a reference around to the source port > >> > > sent to > >> > > you in the onconnect handler. The way I usually do this is via a > >> > > closure:
> >> > > 3) A MessagePort will not deliver onmessage events until you call > >> > > start() > >> > > on it. So if you just use addEventListener("message", function...), > >> > > your > >> > > function won't be called until you call port.start(). If you > register > >> > > an > >> > > event listener by setting the onmessage attribute directly, then it > >> > > starts > >> > > the port for you. Yes, it's very confusing ( > >> > >http://www.w3.org/TR/html5/comms.html#messageport) but the intent is > to > >> > > make sure that ports don't dispatch events until the listener has > been > >> > > added. I never use addEventListener() for exactly this reason but > >> > > instead > >> > > directly set the onmessage attribute.
> >> > > On Mon, Feb 22, 2010 at 8:34 PM, rektide <rekt...@voodoowarez.com> > >> > > wrote:
> >> > >> I'm trying to use SharedWorkers, but not getting anywhere. I > whipped > >> > >> up a quick demoscript where a page "ping"s a SharedWorker and the > >> > >> SharedWorker should "pong" back, but something isnt working, and I > >> > >> have no idea what. The code is running at > >> > >>http://rektide.voodoowarez.com/2010/2/ping.html > >> > >> . Its also pasted below:
> >> > >> Please help me use this incredible feature. I have no idea what > I'm > >> > >> doing wrong. > >> > >> -rektide
> >> > >> -- > >> > >> You received this message because you are subscribed to the Google > >> > >> Groups > >> > >> "Chromium HTML5" group. > >> > >> To post to this group, send email to chromium-ht...@chromium.org. > >> > >> To unsubscribe from this group, send email to
