Re: Sync API for workers

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