> 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.gre...@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" <dtel...@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 >> >