Re: Sync API for workers

Rick:
Thanks for confirming that.

Being more familiar with generators (and other ES6 goodies), can you
envision any setup where a generator (or perhaps multiple yielding to each
other) would enable us to build synchronous API wrappers around async APIs
in JS?
On Oct 13, 2013 6:44 PM, "Rick Waldron" <waldron.rick@gmail.com> wrote:

>
>
> On Sunday, October 13, 2013, James Greene wrote:
>
>> Oh, does `yield` work anywhere? I thought it was only for use within
>> generators. Admittedly, I haven't been keeping up with the latest ES6
>> changes.
>>
>
> yield may only appear in the body of a generator function, denoted by star
> syntax: function* g(){}
>
> Rick
>
>
>
>> On Oct 13, 2013 9:38 AM, "piranna@gmail.com" <piranna@gmail.com> wrote:
>>
>>> Javascript now has support for yield statements the same way Python
>>> does, that's a way to stop (ie. sleep) the execution of a script to allow
>>> another to work and restart from there. It's not their main function, but
>>> allow to create what's called "greenlets", green threads, and that's how I
>>> seen sync APIs are build in top of async ones...
>>> El 13/10/2013 16:21, "James Greene" <james.m.greene@gmail.com> escribió:
>>>
>>>> > a) is necessary, but for b) it is sufficient for the sync thread to be
>>>> > able to sleep until a condition/mutex/... is lifted
>>>>
>>>> In other words, your clarification is completely true but my initial
>>>> statement was written with regard to client-side JavaScript, which cannot
>>>> sleep. As such, I believe my original assertions are still correct with
>>>> regard to writing a sync wrapper in JS.
>>>> On Oct 13, 2013 9:09 AM, "James Greene" <james.m.greene@gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks for adding clarification. That CAN be true but it depends on
>>>>> the environment [so far as I can see].
>>>>>
>>>>> For example, such an API wrapper couldn't be built in today's
>>>>> client-side JavaScript because the UI thread can't do a synchronous
>>>>> yielding "sleep" but rather can only do a synchronous blocking wait, which
>>>>> means it wouldn't yield to allow for the Worker thread to asynchronously
>>>>> respond and toggle such a condition/mutex/etc. unless such can be
>>>>> synchronously requested by the blocking thread from within the busy wait
>>>>> loop (e.g. `processEvents();`) as browsers won't interrupt the synchronous
>>>>> flow of the JS busy loop to trigger `onmessage` handlers for async messages
>>>>> sent from the Worker.
>>>>>
>>>>> If I'm mistaken, please consider providing a code snippet, gist, etc.
>>>>> to get me back on track. Thanks!
>>>>> On Oct 13, 2013 5:06 AM, "David Rajchenbach-Teller" <
>>>>> dteller@mozilla.com> wrote:
>>>>>
>>>>>> On 10/12/13 3:48 PM, James Greene wrote:
>>>>>> > You can only build a synchronous API on top of an asynchronous API
>>>>>> if
>>>>>> > they are (a) running in separate threads/processes AND (b) the sync
>>>>>> > thread can synchronously poll (busy loop) for the
>>>>>> progress/completion of
>>>>>> > the async thread.
>>>>>>
>>>>>> a) is necessary, but for b) it is sufficient for the sync thread to be
>>>>>> able to sleep until a condition/mutex/... is lifted
>>>>>>
>>>>>>
>>>>>> --
>>>>>> David Rajchenbach-Teller, PhD
>>>>>>  Performance Team, Mozilla
>>>>>>
>>>>>