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" <[email protected]> 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 >
