On Tue, Aug 12, 2014 at 3:54 PM, Glenn Maynard <gl...@zewt.org> wrote:
> On Tue, Aug 12, 2014 at 9:21 AM, David Bruant <bruan...@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 <bruan...@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. > +1 - There's a parallel discussion over in https://groups.google.com/a/chromium.org/d/msg/blink-dev/ud14qC8yw30/ddLLwdJz4dgJ about such a thing. I'd be loathe to introduce any worker-only sync variations of a window-exposed async API (like IDB) until we first expose the blocking primitives to the platform that let us implement a polyfill (as Darin suggests) and reason/specify about the sync API (as Jonas suggests). > > > -- > Glenn Maynard > >
