On Tue, Aug 12, 2014 at 9:21 AM, David Bruant <bruant.d@gmail.com> wrote: > With C, Java and all, we already know where adding blocking I/O primitives > leads to. Admittedly maybe dogma trying to learn from history. You still seem to be confusing the issue that I explained earlier. There's nothing wrong with blocking in and of itself, it's doing it in a shared thread like a UI thread that causes problems. On Tue, Aug 12, 2014 at 1:38 PM, David Bruant <bruant.d@gmail.com> wrote: > Workers don't have all the APIs that main-thread JS has today. What's >> more, if one chooses to write async-only code for all contexts, then >> there's no problem. >> > That's not what I had understood. So both types of APIs (sync and async) > will be available to workers for say, IndexedDB? > No, the general idea was that most APIs (especially complex ones, like IDB) would only have async APIs. The block-until-a-message-is-received API (which is all this thread is about) could then be used to create a sync interface for any async interface (or any combination of async interfaces, or for number crunching work in another worker). Nobody said anything about only having sync APIs. -- Glenn Maynard
Received on Tuesday, 12 August 2014 22:54:40 UTC