W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Synchronous postMessage for Workers?

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Sat, 19 Nov 2011 01:42:36 +0100
To: Joshua Bell <jsbell@chromium.org>
Cc: public-webapps@w3.org
Message-ID: <9msdc71l8tcc5blds7pc7eo8eh3nq2c0q3@hive.bjoern.hoehrmann.de>
* Joshua Bell 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.

I note that you can overcome manually coded continuation passing style
by exposing the continuations. In JavaScript 1.7 "Generators" do that in
some limited fashion: a generator can yield control to the calling code,
which can then resume the generator at its discretion, allowing you to
implement Wait functions that wait for whatever you want them waiting
for, for however long you might want them to wait for it. Some years ago
I made http://lists.w3.org/Archives/Public/www-archive/2008Jul/0009.html
as a quick example of using generators in this manner.

The generator there essentially schedules resource loads and yields con-
trol until the resource finishes loading in which case the event handler
would resume the generator. A more realistic example would schedule all
the resources needed to proceed and watch out for load failures and so
on, but it demonstrates that cooperative multitasking is quite feasible.

Obviously, even if "ES.next" provides better support for this, it is a
good bit more complicated to use directly, and easier to get wrong, than
a dedicated solution with limited scope as you propose for this special
case, but adding blocking APIs here and there to address a few use cases
also doesn't strike me as the best approach.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Saturday, 19 November 2011 00:43:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT