Re: [IndexedDB] Why rely on run-to-completion?

The JavaScript engine we have implemented has interpreter continuations. So
at bytecode boundaries it is able to process pending events. (not saying it
currently does this, but it may in the future). This is not multi-threading,
there is only one thread per "engine" which maintains an interpreter
environment and communicates with other engines by message passing (we
already have a worker API, although non-standard).

This could cause a problem with the current API. The fix for this is to make
sure the callbacks are defined before the function using the callbacks is
called.

I think keeping away from multi-threading in JS is sensible (perhaps Erlang
style multi-processing would be good though). However "interrupting" the
interpreter to process callbacks is just a single thread and causes no
problems providing the callbacks are initialised before the call that
initialises the background process that will generate the asynchronous
event.


Cheers,
Keean.


On 30 December 2010 20:44, Jonas Sicking <jonas@sicking.cc> wrote:

> Even if we decide to make the environment in which we run webpage
> script multithreaded the current API will work fine. Generally
> speaking in multithreaded environments you do callbacks on the same
> thread as which the initial function is called.
>
> Alternatively you'd want to pass in the thread on which you want
> callbacks, along with the callbacks you want called. But in that case
> using EventTargets doesn't make sense as you don't know if a callback
> has already happened by the time you call addEventListener. Likewise,
> the readyState property also would need to be removed as by the time
> you check it it can already be out of date. In short, a complete
> revamping of the API would be needed, the small modification you are
> proposing would be nowhere near enough.
>
> However most of all I'm not terribly worried that we'll make the
> browser scripting environment multitheaded. Multithreading is
> extremely complicated. To this day research is still happening on how
> to implement even the most simple datastructures, such as queues and
> hash tables, effectively in a mulithreaded environment. See the
> discussions on the WhatWG list which took place when we designed the
> workers API.
>
> I find it much more likely that we'll stick with the approach that
> workers have introduced of having separate environments which run on
> different threads and with no shared state. Communication between
> threads happen through message passing. This is similar to languages
> such as Google's Go and Mozilla's Rust.
>
> / Jonas
>
> On Thu, Dec 30, 2010 at 12:45 AM, Axel Rauschmayer <axel@rauschma.de>
> wrote:
> > Right. But is there anything one loses by not relying on it, by making
> the API more generic?
> >
> > On Dec 30, 2010, at 7:58 , Jonas Sicking wrote:
> >
> >> On Wed, Dec 29, 2010 at 2:44 PM, Axel Rauschmayer <axel@rauschma.de>
> wrote:
> >>> Can someone explain a bit more about the motivation behind the current
> design of the async API?
> >>>
> >>>> var request = window.indexedDB.open(...);
> >>>> request.onsuccess = function(event) { ... };
> >>>
> >>> 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?
> >>>
> >>> Maybe it is just me, but I would like it better if the last argument
> was an object with the error and the success continuations (they could also
> be individual arguments). That is also how current JavaScript RPC APIs are
> designed, resulting in a familiar look. Are there any arguments *against*
> this approach?
> >>>
> >>> Whatever the reasoning behind the design, I think it should be
> explained in the spec, because the current API is a bit tricky to understand
> for newbies.
> >>
> >> Note that almost everyone relies on this anyway. I bet that almost all
> >> code out there depends on that the code in for example onload handlers
> >> for XHR requests run after the current thread of execution has fully
> >> finished.
> >>
> >> Asynchronous events isn't something specific to javascript.
> >>
> >> / Jonas
> >>
> >
> > --
> > Dr. Axel Rauschmayer
> > Axel.Rauschmayer@ifi.lmu.de
> > http://hypergraphs.de/
> > ### Hyena: organize your ideas, free at hypergraphs.de/hyena/
> >
> >
> >
> >
>
>