Re: BlobBuilder.append() should take ArrayBufferView in addition to ArrayBuffer
On Apr 12, 2012, at 2:48 PM, Arun Ranganathan wrote: I intend to add ArrayBufferView as a parameter to the Blob constructor . Would it be possible also to allow passing an ArrayBuffer with an offset and length as an additional alternative? This would eliminate the need to create a view when you just want a slice of the buffer but don't particularly want/need to think of it as a Uint8/Uint32/whatever array. Dave
Re: BlobBuilder.append() should take ArrayBufferView in addition to ArrayBuffer
On Apr 24, 2012, at 3:53 PM, David Herman wrote: On Apr 12, 2012, at 2:48 PM, Arun Ranganathan wrote: I intend to add ArrayBufferView as a parameter to the Blob constructor . Would it be possible also to allow passing an ArrayBuffer with an offset and length as an additional alternative? This would eliminate the need to create a view when you just want a slice of the buffer but don't particularly want/need to think of it as a Uint8/Uint32/whatever array. Oh, I just saw in the bug that the idea is to *eliminate* the ArrayBuffer argument option entirely. If that's the case then disregard my question. Dave
Re: Synchronous postMessage for Workers?
On Feb 16, 2012, at 7:06 AM, Glenn Maynard wrote:
On Wed, Feb 15, 2012 at 12:39 AM, Jonas Sicking jo...@sicking.cc wrote:
Put it another way, when you spin the event loop, not only does your
code need to be prepared for anything happening. All functions up the
call stack also has to. That makes it very hard to reason about any of
your code, not just the code that calls yieldUntil.
FWIW, I've used similar mechanisms, such as Lua coroutines, and it worked
well.
It works well when you know that the function you're calling is blocking. As
Boris, Mark, and Jonas have said, it doesn't work so well as your code starts
growing and you lose track of who might be blocking when.
The message polling/blocking can be done without spinning the event loop, of
course. It would be nice to have capabilities like running two sync XHRs,
but with message blocking, you'd be able to do that yourself with a bit more
work (spin up two workers to do the XHRs, then block on response messages).
Using workers for this is heavyweight. It works very nicely in ES6 with task.js:
spawn(function*() {
try {
var [file1, file2] = yield join(xhr(file1.txt), xhr(file2.txt));
element1.innerHTML = file1;
element2.innerHTML = file2;
} catch (e) {
console.log(error: + e);
}
});
The difference between task.js and continuations/coroutines/synchronous workers
is that the blocking is always explicitly labelled with `yield`. So you can
never accidentally call a function that might suspend your stack and allow
other code to run in between.
I wrote about this recently:
http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/
A commenter correctly pointed out that the worker approach makes it easier for
engines to capture native frames, so maybe it's not so onerous for implementors
as my post makes it out to be. But we made a conscious choice in TC39 *not* to
add full coroutines to JS because of the fragility of implicit suspension.
Dave
Re: [IndexedDB] Why rely on run-to-completion?
On Dec 29, 2010, at 2:44 PM, Axel Rauschmayer wrote:
The pattern of assigning the success continuation after invoking the
operation seems to be to closely tied to JavaScript’s current
run-to-completion event handling. But what about future JavaScript
environments, e.g. a multi-threaded Node.js with IndexedDB built in or Rhino
with IndexedDB running in parallel? Wouldn’t a reliance on run-to-completion
unnecessarily limit future developments?
As a long-time member of the ECMAScript standardization effort, I usually avoid
making predictions about the future of JS, but I feel pretty confident
predicting that the language is not going to evolve to support pre-emptive,
shared-memory threading. See e.g. Brendan Eich's blog post from a few years ago:
http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html
I don't think you need to worry about JS acquiring pre-emption semantics. We
*are* working on standardizing generators, which are a sort of explicit
pre-emption mechanism; in that case a programmer might write:
var request = window.indexedDB.open(...);
yield;// relinquish control...
request.onsuccess = function(event) { ... }; // oops, too late
but arguably that's not such a big deal since the programmer has explicitly
done the assignment after yielding control.
All that said, I agree with you that the API design requiring the programmer to
assign listeners mutably, rather than being able to use the more functional
approach, is clunky.
Dave
