Re: Sync API for workers

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 <javascript:_e({}, 'cvml',
> 'piranna@gmail.com');>" <piranna@gmail.com <javascript:_e({}, 'cvml',
> '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<javascript:_e({}, 'cvml', '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<javascript:_e({}, 'cvml', '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 <javascript:_e({}, 'cvml', '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
>>>>>
>>>>