Re: Sync API for workers

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