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

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

> On Thu, Dec 30, 2010 at 2:19 PM, Keean Schupke <keean@fry-it.com> wrote:
> > 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.
>
> If you are interrupting at arbitrary points in the execution and
> running other script contexts which can synchronously call into the
> first javascript context, then you are implementing multithreading.
> This is in fact exactly how multithreading works on single-core CPUs.
> It means that you are exposing race conditions and all other threading
> hazards to webpages.
>
> / Jonas
>

That makes complete sense to me, although not all threading hazards would be
exposed, as partial writes will not be a problem, all variable accesses will
automatically be atomic.  But yes, race conditions would be a problem with
interrupts so I agree its a bad idea.  (The interpreter continuations are
currently used to store interpreter state when executing a blocking IO
action, so that other engines can carry on running when running in a single
threaded environment).

In that case I can't see any limitations to the current API.

As for the aesthetic considerations, the way JavaScript works is by events,
it makes more sense to expose the API as events rather than callbacks, as
callbacks give the false impression that the callback can happen at any
time.


Cheers,
Keean.