Re: Blocking message passing for Workers

On Tue, Aug 12, 2014 at 3:54 PM, Glenn Maynard <glenn@zewt.org> wrote:

> 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.
>

+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
>
>