Le 10/03/2013 21:17, David Rajchenbach-Teller a écrit :
On 3/9/13 1:14 AM, Glenn Maynard wrote:
I don't think making a call asynchronous is really going to help much,
at least for serialization. You'd have to make a copy of the data
synchronously, before returning to the caller, in order to guarantee
that changes made after the call returns won't affect the result. This
would probably be more expensive than the JSON serialization itself,
since it means allocating lots of objects instead of just appending to a
string.
If it's possible to make that copy quickly, then that should be done for
postMessage itself, to make postMessage return quickly, instead of doing
it for a bunch of individual computationally-expensive APIs.
(Also, remember that "returns quickly and does work asynchronously"
doesn't mean the work goes away; the CPU time still has to be spent.
Serializing the complete state of a large system while it's running and
trying to maintain 60 FPS doesn't sound like a good approach in the
first place.)
I concur with your points:
- copying synchronously just to allow asynchronous transfer would be a
performance killer;
- somehow backgrounding a process while keeping processing on the
performance-critical thread is no magic bullet.
Both points seem to indicate that the API should not be of the
fire-and-forget style but would rather require fine control by the
developer, to ensure that it does not eat on performances.
Hypothetically, this could be solved by an API with primitives to:
1. enqueue data to be sent;
2. allocate x milliseconds to processing/sending the data;
3. cancel sending some of the data;
4. cancel complete communication.
Could you expand on how you came to these 4 primitives, please?
It feels like a lot of reflection came from the current discussion to
this conclusion, but I fail to understand it. Maybe one way to explain
these 4 primitives would be to show how you want to solve the "save
browser state" problem using them without freezing the browser.
In any case, ECMAScript 7 will very likely "steal" the event loop [1]
from HTML5 and it seems that the primitive you're describing and the
reflection that came to them would be worthwhile in the event loop
reflection.
Maybe some part of this discussion should be moved to es-discuss or
public-script-coord at some point.
The idea being that all operations have (soft) time bound guarantees so
can be interleaved by the user as part of a |requestAnimationFrame|
loop. Also, data is never copied, so if this data changes before
communication is complete, API clients need to handle invalidation on
their own.
Now, this sounds very much like something that can be implemented as a
pure JS library.
I'm particularly puzzled about that especially on the "allocate x
milliseconds to processing/sending the data", but I'm waiting for your
explanations above to better understand what you mean.
David
[1] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop
Seriously?
FirefoxOS [1, 2] is a mobile operating system in which all applications
are written in JavaScript, HTML, CSS. This includes the browser itself.
[...]
That doesn't sound like a good idea to me at all, but in any case that's
a system platform, not the Web.
[...]
If you do not mind, I will not continue on this part of the
conversation, as I believe that the core of the discussion has shifted
anyway to the more general issue of sending large structured data
between threads without compromising their responsiveness.
Best regards,
David
