- From: David Levin <levin@chromium.org>
- Date: Thu, 17 Nov 2011 14:07:31 -0800
- To: Joshua Bell <jsbell@chromium.org>
- Cc: public-webapps@w3.org
- Message-ID: <CACmjMJQQ6of09PbmqCQTow+Y4F_P7CzKJ3Dc8HOCzdX9pJqGnA@mail.gmail.com>
It seems like this mechanism would deadlock a worker if two workers send each other a synchronous message. dave On Thu, Nov 17, 2011 at 10:37 AM, Joshua Bell <jsbell@chromium.org> wrote: > Jonas and I were having an offline discussing regarding the synchronous > Indexed Database API and noting how clean and straightforward it will allow > Worker scripts to be. One general Worker issue we noted - independent of > IDB - was that there are cases where Worker scripts may need to fetch data > from the Window. This can be done today using bidirectional postMessage, > but of course this requires the Worker to then be coded in now common > asynchronous JavaScript fashion, with either a tangled mess of callbacks or > some sort of Promises/Futures library, which removes some of the benefits > of introducing sync APIs to Workers in the first place. > > Wouldn't it be lovely if the Worker script could simply make a synchronous > call to fetch data from the Window? > > GTNW.prototype.end = function () { > var result = self.sendMessage({action: "prompt_user", prompt: "How > about a nice game of chess?"}); > if (result) { chess_game.begin(); } > } > > The requirement would be that the Window side is asynchronous (of course). > Continuing the silly example above, the Window script responds to the > message by fetching some new HTML UI via async XHR, adding it to the DOM, > and only after user input and validation events is a response sent back to > the Worker, which proceeds merrily on its way. > > I don't have a specific API suggestion in mind. On the Worker side it > should take the form of a single blocking call taking the data to be passed > and possibly a timeout, and allowing a return value (on > timeout return undefined or throw?). On the Window side it could be a new > event on Worker which delivers a "Promise" type object which the Window > script can later fulfill (or break). Behavior on multiple event listeners > would need to be defined (all get the same "Promise", first "fulfill" wins, > others throw?). > >
Received on Thursday, 17 November 2011 22:08:29 UTC