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. Rick > -- > Glenn Maynard > >
Received on Friday, 18 November 2011 00:29:27 UTC