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