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

Re: Synchronous postMessage for Workers?

From: Rick Waldron <waldron.rick@gmail.com>
Date: Thu, 17 Nov 2011 19:28:36 -0500
Message-ID: <CAHfnhfrEns6kfGAZhO8F9GZ5c70YrE6MTzp_V=oK77u6G6zdSQ@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Joshua Bell <jsbell@chromium.org>, "public-webapps@w3.org" <public-webapps@w3.org>
On Thu, Nov 17, 2011 at 6:50 PM, Glenn Maynard <glenn@zewt.org> wrote:

> On Thu, Nov 17, 2011 at 6:17 PM, Rick Waldron <waldron.rick@gmail.com>wrote:
>> No, it's not. Messaging should not block either process.
> No, it's perfectly fine to block a worker, as long as the worker
> explicitly requests it and is expecting it.
> I don't know what that means.  Synchronous APIs are one of the major
>> reasons to have Workers in the first place.
>> Considering the current messaging API and the allowed host APIs, I
>> strongly disagree.
> I'm not quite sure what you mean by "allowed host APIs", but there are
> lots of synchronous APIs in Workers: File API, Filesystem API, IndexedDB.
> These are all new APIs, not historical accidents (like sync XHR in the UI
> thread).  Synchronous (blocking) APIs in workers is entirely by design, in
> order to allow writing clean, linear code instead of code that has to yield
> to the calling environment all the time.

Sorry, I should've been clearer - I was referring to the renderer-to-worker
messaging API - all event based, all async.

TBH, at this point I'd be more interested in an actual prototype
implementation to see the effects it would have on Worker to Worker
messaging, SharedWorker etc.


> --
> Glenn Maynard
Received on Friday, 18 November 2011 00:29:27 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC