Look at IndexedDB API, since asynchronous one was enought dfor everybody,
synchronous one was not implemented by the browsers and now it has became
deprecated... :-)
Well regarding my position I would not smile ;-)
I was considering a server-side implementation of indexedDB. There is
Let me introduce the first sketch of a variant. The general idea is to
add a |postSyncMessage|
We extend DedicatedWorkerGlobalScope and MessageEvent as follows:
interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
void postMessage(any message, optional sequenceTransferable transfer);
On 10/13/13 4:21 PM, James Greene wrote:
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
- Original Message -
From: David Bruant bruan...@gmail.com
To: Jonas Sicking jo...@sicking.cc
Cc: public-webapps public-webapps@w3.org, aza...@mozilla.com
Sent: Sunday, October 13, 2013 1:36:22 PM
Subject: Re: Sync API for workers
* You could solve the use case of compile-to-JS
On Mon, Oct 14, 2013 at 2:33 AM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
Let me introduce the first sketch of a variant. The general idea is to
add a |postSyncMessage|
We extend DedicatedWorkerGlobalScope and MessageEvent as follows:
interface DedicatedWorkerGlobalScope :
You snipped the comment about waitForMessage(). I think it should return
an Event, as if the message had been received from onmessage, not just the
received data.
On Sun, Oct 13, 2013 at 10:37 PM, Jonas Sicking jo...@sicking.cc wrote:
This is certainly an improvement over the previous
This meant to be a more limited and well-behaved variant.
However, as pointed out by Jonas, a very similar proposal has been
submitted and discussed long before I joined this list. So, please
disregard my proposal, it is an artifact of me not searching the
archives well enough.
Best regards,
Could we change the method name under discussion to `postMessageSync`
instead of `postSyncMessage`? I know they're not grammatically equivalent
but I've always found the *Sync suffixes used on pertinent Node.js APIs to
be much more intuitive than trying to guess which position within a string
of
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
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
When I see discussion of any new/recent synchronous APIs for the Web
platform these days I pretty much take it they're implicitly intended just
for use with Workers. So I assume that's the context Jonas intended.
It's a safe assumption, but I think it's better to be asynchronous also on
Synchronous APIs are easier to use since it's how things have been done
since decades ago,
No, they're easier to use because they fit the model of linear human
thought more naturally. The idea that asynchronous APIs are just as good
and easy as synchronous APIs, and that people only disagree
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.
On Oct 12, 2013 1:23 AM, pira...@gmail.com pira...@gmail.com wrote:
On Wed, Sep 5, 2012 at 7:03 PM, Jonas Sicking jo...@sicking.cc wrote:
Hence I think something like the following would work:
[Constructor]
interface SyncMessageChannel {
readonly attribute MessagePortSyncSide syncPort;
readonly attribute MessagePortAsyncSide asyncPort;
};
interface
* Enable compiling code that was written for other platforms to the
web. Specifically where such code uses synchronous APIs, but where we
for good reasons have chosen not to expose synchronous counterparts in
the web platform. The most obvious example here is synchronous
filesystem access
pira...@gmail.com pira...@gmail.com, 2013-10-11 21:24 +0200:
[Jonas said]:
* Enable compiling code that was written for other platforms to the
web. Specifically where such code uses synchronous APIs, but where we
for good reasons have chosen not to expose synchronous counterparts in
the
On Fri, Oct 11, 2013 at 2:24 PM, pira...@gmail.com pira...@gmail.comwrote:
Synchronous APIs are easier to use since it's how things have been done
since decades ago,
No, they're easier to use because they fit the model of linear human
thought more naturally. The idea that asynchronous APIs
On Thu, Sep 6, 2012 at 7:18 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, Sep 6, 2012 at 12:31 AM, Jonas Sicking jo...@sicking.cc wrote:
That is certainly an interesting use case. I think another interesting
use case is being able to write synchronous APIs in workers whose
implementation
On Wed, Sep 5, 2012 at 11:02 PM, b...@pettay.fi b...@pettay.fi wrote:
On 09/06/2012 08:31 AM, Jonas Sicking wrote:
On Wed, Sep 5, 2012 at 8:07 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Sep 5, 2012 at 2:49 AM, Jonas Sicking jo...@sicking.cc wrote:
The problem with a Only allow
On 09/06/2012 09:12 AM, Jonas Sicking wrote:
On Wed, Sep 5, 2012 at 11:02 PM, b...@pettay.fi b...@pettay.fi wrote:
On 09/06/2012 08:31 AM, Jonas Sicking wrote:
On Wed, Sep 5, 2012 at 8:07 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Sep 5, 2012 at 2:49 AM, Jonas Sicking jo...@sicking.cc
On 09/06/2012 09:30 AM, Olli Pettay wrote:
On 09/06/2012 09:12 AM, Jonas Sicking wrote:
On Wed, Sep 5, 2012 at 11:02 PM, b...@pettay.fi b...@pettay.fi wrote:
On 09/06/2012 08:31 AM, Jonas Sicking wrote:
On Wed, Sep 5, 2012 at 8:07 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Sep 5, 2012
On Wed, Sep 5, 2012 at 11:56 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 09/06/2012 09:49 AM, Jonas Sicking wrote:
On Wed, Sep 5, 2012 at 11:30 PM, Olli Pettay olli.pet...@helsinki.fi
wrote:
On 09/06/2012 09:12 AM, Jonas Sicking wrote:
On Wed, Sep 5, 2012 at 11:02 PM, b...@pettay.fi
Just to ping a detail, so it's not lost in history: it should also be
possible to peek at a
On Thu, Sep 6, 2012 at 12:31 AM, Jonas Sicking jo...@sicking.cc wrote:
1: allow blocking upwards, 2: allow blocking downwards,
Indeed. But I believe #2 is more useful than #1. I wasn't proposing
On Mon, Sep 3, 2012 at 8:55 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Sep 3, 2012 at 9:30 PM, Jonas Sicking jo...@sicking.cc wrote:
We can't generically block on children since we can't let the main
window block on a child. That would effectively permit synchronous IO
from the main
On Wed, Sep 5, 2012 at 7:03 PM, Jonas Sicking jo...@sicking.cc wrote:
[Constructor]
interface MessageChannel {
readonly attribute MessagePortSyncSide syncPort;
readonly attribute MessagePortAsyncSide asyncPort;
};
This should of course say SyncMessageChannel.
/ Jonas
On Wed, Sep 5, 2012 at 2:49 AM, Jonas Sicking jo...@sicking.cc wrote:
The problem with a Only allow blocking on children, except that
window can't block on its children is that you can never block on a
computation which is implemented in the main thread. I think that cuts
out some major use
On Wed, Sep 5, 2012 at 8:07 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Sep 5, 2012 at 2:49 AM, Jonas Sicking jo...@sicking.cc wrote:
The problem with a Only allow blocking on children, except that
window can't block on its children is that you can never block on a
computation which is
Hi,
Before anything else, thanks for this detailed and quite complete
explanation.
Le 03/09/2012 23:32, Jonas Sicking a écrit :
The other thing that I wanted to talk about is use cases. It has been
claimed in this thread that synchronous message passing isn't needed
and that people can just
On 9/4/12 5:23 AM, David Bruant wrote:
Also, I wish the demand came from the people who do work on Emscripten
or Mandreel
As far as I know, what Jonas is saying about Emscripten did come from
the Emscripten folks. I've certainly seen them say it in bugs in the
recent past. No guessing
Le 04/09/2012 14:34, Boris Zbarsky a écrit :
On 9/4/12 5:23 AM, David Bruant wrote:
Also, I wish the demand came from the people who do work on Emscripten
or Mandreel
As far as I know, what Jonas is saying about Emscripten did come from
the Emscripten folks. I've certainly seen them say it
On 9/4/12 8:54 AM, David Bruant wrote:
Ok I wasn't aware of that. Do you have bug numbers in mind by any chance?
I don't offhand, unfortunately. Would have to search.
-Boris
On Tue, Sep 4, 2012 at 4:23 AM, David Bruant bruan...@gmail.com wrote:
The proposed solution here throws away all benefits of async code to
reduce the complexity of writing async code by... writing sync code.
I wish we'd explore more solutions to make async more workable rather than
throwing
Le 04/09/2012 17:03, Glenn Maynard a écrit :
On Tue, Sep 4, 2012 at 4:23 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
The proposed solution here throws away all benefits of async code
to reduce the complexity of writing async code by... writing sync
code.
On Tue, Sep 4, 2012 at 10:32 AM, David Bruant bruan...@gmail.com wrote:
Cognitive load is the only one mentioned so far. It is a serious issue
since for the foreseeable future, only human beings will be writing code.
However, as said, there are solutions to reduce this load.
I wish to share
Le 04/09/2012 18:46, Glenn Maynard a écrit :
On Tue, Sep 4, 2012 at 10:32 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Cognitive load is the only one mentioned so far. It is a serious
issue since for the foreseeable future, only human beings will be
On Tue, Sep 4, 2012 at 12:49 PM, David Bruant bruan...@gmail.com wrote:
I'm sorry, but I have to disagree. Have you ever used promises in a
large-scale project?
I've been amazed to discover that promise-based API are ridiculously much
easier to refactor than callback-based API. Obviously,
Le 04/09/2012 20:47, Glenn Maynard a écrit :
On Tue, Sep 4, 2012 at 12:49 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
I'm sorry, but I have to disagree. Have you ever used promises in
a large-scale project?
I've been amazed to discover that promise-based
On Tue, Sep 4, 2012 at 2:23 PM, David Bruant bruan...@gmail.com wrote:
Tooling isn't perfect for async debugging. It's being worked on. Yet it
hasn't prevented web devs from buiding (and debugging) event-based code.
Developers work in lots of bad environments and get stuff done anyway.
That's
On Mon, 3 Sep 2012, Glenn Maynard wrote:
- Add an internal flag to MessagePort, blocking permitted, which is
initially set.
- When a MessagePort port is transferred from source to dest,
- If source is an ancestor of dest, the blocking permitted flag of
port is cleared. (This is a down
[Forwarding a response from Alon Zakai, who is behind Emscripten and
CC'ing him]
There is also another use-case which has been brought up. As the
web
platform is becoming more powerful, people have started converting
code written for other platforms to javascript+html.
By html, here, do
Alon Zakai wrote:
Technically it might
be possible to automatically rewrite such code to use asynchronous
coding patterns, but so far I don't think anyone has managed to do
that.
Naively, I would say, that once we've paid the price to compile code
from one language to another, you're not
David Bruant wrote:
I can imagine, it sounds hard indeed. Do you have numbers on how it
affects performance? Or an intuition on these numbers? I don't need to
be convinced that it affects performance significantly, but just to get
an idea.
This is not going to be easy to estimate, but you
On Tue, Sep 4, 2012 at 3:11 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 3 Sep 2012, Glenn Maynard wrote:
- Add an internal flag to MessagePort, blocking permitted, which is
initially set.
- When a MessagePort port is transferred from source to dest,
- If source is an ancestor of
On Mon, Sep 3, 2012 at 10:55 PM, Glenn Maynard gl...@zewt.org wrote:
I suspect there's a way to make the general-case version work, though.
To restate this by itself instead of as a delta:
- Add an internal flag to MessagePort, blocking permitted, which is
initially set. Add a value previous
On Tue, Sep 4, 2012 at 1:59 PM, Brendan Eich bren...@mozilla.org wrote:
David Bruant wrote:
I can imagine, it sounds hard indeed. Do you have numbers on how it
affects performance? Or an intuition on these numbers? I don't need to
be convinced that it affects performance significantly, but
On Sat, Sep 1, 2012 at 11:49 AM, David Bruant bruan...@gmail.com wrote:
Also, I don't think I have seen mentionned use cases of things that are
not possible without a Sync API. Everything presented is already
possible (sometimes at arguably high costs like Glenn Maynard's use case
in
Hi All,
I'd like to start by clearing up some confusion here. That's why I'm
responding to the first email in this thread.
We at mozilla have no interest in creating an API which runs the risk
of causing dead-locks. I would expect this to be true of other browser
vendors too, though obviously I
On Mon, Sep 3, 2012 at 4:47 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Sep 3, 2012 at 4:32 PM, Jonas Sicking jo...@sicking.cc wrote:
It seems hard to ensure that deadlocks can't happen if we try to allow
blocking calls on generic MessagePorts, this is why we haven't been
interested in
On Mon, Sep 3, 2012 at 9:30 PM, Jonas Sicking jo...@sicking.cc wrote:
We can't generically block on children since we can't let the main
window block on a child. That would effectively permit synchronous IO
from the main thread which is not something that we want to allow.
The UI thread
On Sat, Sep 1, 2012 at 2:32 PM, Glenn Maynard gl...@zewt.org wrote:
On Sat, Sep 1, 2012 at 3:19 PM, Rick Waldron waldron.r...@gmail.comwrote:
I can seriously dispute this, as someone who involved in research and
development of JavaScript programming for hardware. Processing high volume
On Sun, Sep 2, 2012 at 12:24 PM, Andrew Wilson atwil...@google.com wrote:
Just wanted to point out that all of the arguments for a wait-for-reply
API in workers also apply to SharedWorkers. It's trickier for SharedWorkers
since they use MessagePorts, and we probably don't want to expose this
On Sun, 2 Sep 2012, Andrew Wilson wrote:
Just wanted to point out that all of the arguments for a wait-for-reply API
in workers also apply to SharedWorkers. It's trickier for SharedWorkers
since they use MessagePorts
Dedicated Workers use MessagePorts too, they're just embedded in the
On Sun, Sep 2, 2012 at 12:16 PM, Glenn Maynard gl...@zewt.org wrote:
On Sun, Sep 2, 2012 at 12:24 PM, Andrew Wilson atwil...@google.comwrote:
I am not optimistic that we can do deadlock prevention in the general
case with MessagePorts, for the same reason that it's prohibitively
difficult to
On Sat, Sep 1, 2012 at 11:49 AM, David Bruant bruan...@gmail.com wrote:
A Sync API for workers is being implemented in Firefox [1].
I'd like to come back to the discussions mentionned in comment 4 of the
bug.
A summary of points I find important and my comments, questions and
concerns
#
On 09/01/2012 11:19 PM, Rick Waldron wrote:
David,
Thanks for preparing this summary—I just wanted to note that I still stand
behind my original, reality based arguments.
One comment inline..
On Saturday, September 1, 2012 at 12:49 PM, David Bruant wrote:
Hi,
A Sync API for workers is
On Saturday, September 1, 2012 at 4:02 PM, Glenn Maynard wrote:
On Sat, Sep 1, 2012 at 11:49 AM, David Bruant bruan...@gmail.com
(mailto:bruan...@gmail.com) wrote:
A Sync API for workers is being implemented in Firefox [1].
I'd like to come back to the discussions mentionned in comment
On Saturday, September 1, 2012 at 4:28 PM, Olli Pettay wrote:
On 09/01/2012 11:19 PM, Rick Waldron wrote:
David,
Thanks for preparing this summary—I just wanted to note that I still stand
behind my original, reality based arguments.
One comment inline..
On Saturday,
My reading (from the proposed APIs) is that these are only synchronous from the
Worker's PoV. If that's correct I have no real objections to such an API - the
render thread simply sees a regular message. It doesn't even need a special
API on the receiving side. If the Worker has
...
var
On Sat, Sep 1, 2012 at 4:51 PM, Oliver Hunt oli...@apple.com wrote:
My reading (from the proposed APIs) is that these are only synchronous
from the Worker's PoV. If that's correct I have no real objections to such
an API - the render thread simply sees a regular message. It doesn't even
On 09/01/2012 11:38 PM, Rick Waldron wrote:
So far, they all look async. Just calling them sync doesn't make them sync.
Sure they are sync. They are sync inside worker. We all know that we must not
introduce
new sync APIs in the main thread.
Le 01/09/2012 22:30, Rick Waldron a écrit :
On Saturday, September 1, 2012 at 4:02 PM, Glenn Maynard wrote:
On Sat, Sep 1, 2012 at 11:49 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
# Discussion 2
## Joshua Bell [5]
This can be done today using bidirectional
On Sat, Sep 1, 2012 at 5:12 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 09/01/2012 11:38 PM, Rick Waldron wrote:
So far, they all look async. Just calling them sync doesn't make them
sync.
Sure they are sync. They are sync inside worker. We all know that we must
not introduce
new
On Sat, Sep 1, 2012 at 3:19 PM, Rick Waldron waldron.r...@gmail.com wrote:
I can seriously dispute this, as someone who involved in research and
development of JavaScript programming for hardware. Processing high volume
serialport IO is relatively simple with streams and data events. It's just
78 matches
Mail list logo
