- From: James Greene <james.m.greene@gmail.com>
- Date: Sun, 13 Oct 2013 11:27:40 -0500
- To: piranna@gmail.com
- Cc: David Bruant <bruant.d@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Glenn Maynard <glenn@zewt.org>, public-webapps <public-webapps@w3.org>, David Rajchenbach-Teller <dteller@mozilla.com>, Andrea Marchesini <amarchesini@mozilla.com>
- Message-ID: <CALrbKZiqG9WRKZu07SMYc+pVH7fvhyHVCbYgjA1tYDHO5ppCLw@mail.gmail.com>
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. On Oct 13, 2013 9:38 AM, "piranna@gmail.com" <piranna@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.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 >>>> >>>
Received on Sunday, 13 October 2013 16:28:08 UTC