- From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Date: Mon, 17 Dec 2012 19:28:22 +0200
- To: Marcos Caceres <marcosscaceres@gmail.com>
- Cc: "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <CAJhzemXWv23Me6sf3JcD8TcVZjdsfcHOwiy96To9OFAQyJi=3A@mail.gmail.com>
On Mon, Dec 17, 2012 at 7:01 PM, Marcos Caceres <marcosscaceres@gmail.com>wrote: > > > > On Monday, December 17, 2012 at 4:44 PM, Jussi Kalliokoski wrote: > > > Now, if we had a serializer and it worked like I think it does, we'd > have a possible backwards compatibility issue introducing this > functionality, because the port would have been previously a plain JS > object whereas now it would be a MIDIPort instance. Not that it's very > likely that we'd have a backwards-compatibility issue like this. :D > > > Asked in #WHATG: > marcos: Peoples, quick question... can adding a WebIDL serializer to an > object cause conflicts with Web Workers? > http://lists.w3.org/Archives/Public/public-audio/2012OctDec/0722.html > Ms2ger: marcosc, no, that's nonsense > Ms2ger: If input is a host object (e.g. a DOM node) > Ms2ger: Throw a DataCloneError exception and abort the overall structured > clone algorithm. > marcosc: right, that's what I thought > marcosc: thanks Ms2ger :) > > > == > > Our Input (MIDIPort) is a host object, so it can be treated as a > structured clone. So I think we are sweet there. However, we need to look > at how to specify that properly. > > Need to find some examples of things that can be passed around safely to > worker contexts (I've little experience with workers, but happy to help do > the research if you point me in the right direction). Ok, great news! I've added a bug for this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20415 Transferables are defined here: http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#transferable-objectsand AFAIK currently only implemented for ArrayBuffers, but also in the proposal Hixie made for Canvas in Web Workers, canvas contexts would be transferable. I don't know of any precedents for copyable host objects. :/ But that would be preferable in our case, since ports with read access have only read access and ports with write access have only write access, so I can't think of possible race conditions. Cheers, Jussi
Received on Monday, 17 December 2012 17:28:50 UTC