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
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
Actually only IDBRequest need to be sync, which are prone to error and
complicate workflow. Async workflow on database opening and transaction
request are fine.
Kyaw
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
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
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, pira...@gmail.com pira...@gmail.com wrote:
Javascript now has support for yield statements the same way Python does,
Don't know, I only know behavior of Python yield statement, but Javascript
one was developed following it and I'm 90% secure it follows the same
behaviour (almost all new functionalities of Javascript are being borrowed
from Python since seems Mozilla Javascript implementors are Python
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23487
Bug ID: 23487
Summary: Actually define going fullscreen
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
On 10/13/13 6:33 PM, pira...@gmail.com wrote:
Don't know, I only know behavior of Python yield statement, but
Javascript one was developed following it and I'm 90% secure it follows
the same behaviour (almost all new functionalities of Javascript are
being borrowed from Python since seems
Demostration by example, thanks :-)
2013/10/13 David Rajchenbach-Teller dtel...@mozilla.com:
On 10/13/13 6:33 PM, pira...@gmail.com wrote:
Don't know, I only know behavior of Python yield statement, but
Javascript one was developed following it and I'm 90% secure it follows
the same behaviour
Ok, this thread is clearly heading off the deep end. Let me clear up a
few points of confusion:
* You can not wrap a truly synchronous library around an asynchronous
API. Spinning the event loop gets you close, but breaks
run-to-completion. Furthermore, spinning the event loop is irrelevant
as we
Le 13/10/2013 21:39, Jonas Sicking a écrit :
Ok, this thread is clearly heading off the deep end. Let me clear up a
few points of confusion:
* You can not wrap a truly synchronous library around an asynchronous
API. Spinning the event loop gets you close, but breaks
run-to-completion.
On Sun, Oct 13, 2013 at 1:36 PM, David Bruant bruan...@gmail.com wrote:
Le 13/10/2013 21:39, Jonas Sicking a écrit :
Ok, this thread is clearly heading off the deep end. Let me clear up a
few points of confusion:
* You can not wrap a truly synchronous library around an asynchronous
API.
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*
Rick:
Thanks for confirming that.
Being more familiar with generators (and other ES6 goodies), can you
envision any setup where a generator (or perhaps multiple yielding to each
other) would enable us to build synchronous API wrappers around async APIs
in JS?
On Oct 13, 2013 6:44 PM, Rick Waldron
What I really dislike about this is that the worker can't send the port
directly to a UI thread if it's a nested worker; it has to send it to its
parent, who has to forward it to its parent, and so on. That seems like
it'll make it hard to implement libraries, since libraries needs to have
its
On Sun, Oct 13, 2013 at 8:11 PM, Glenn Maynard gl...@zewt.org wrote:
- Descendants of a MessagePortSyncSide's initial thread are always legal
threads. Additionally, if the port's transferred first value is true, the
initial thread itself is also a legal thread.
- Ancestors of a
On Sun, Oct 13, 2013 at 8:19 PM, Glenn Maynard gl...@zewt.org wrote:
On Sun, Oct 13, 2013 at 8:11 PM, Glenn Maynard gl...@zewt.org wrote:
- Descendants of a MessagePortSyncSide's initial thread are always legal
threads. Additionally, if the port's transferred first value is true, the
initial
On Oct 11, 2013, at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa rn...@apple.com wrote:
On Oct 7, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote:
On Oct 7, 2013 6:56 AM, Hajime Morrita morr...@google.com wrote:
Hi,
I'm sorry
On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa rn...@apple.com wrote:
On Oct 11, 2013, at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa rn...@apple.com wrote:
On Oct 7, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote:
On Oct 7, 2013 6:56
20 matches
Mail list logo
