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

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

Received on Thursday, 30 December 2010 23:09:43 UTC