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

On Thu, Dec 30, 2010 at 5:19 PM, Keean Schupke <keean@fry-it.com> wrote:
> 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.

Delivering events between VM bytecodes is very similar to threading:
it makes code much less deterministic, causing many of the same
problems: race conditions depending on where operations and events
intersect.

For example, it's very hard in most high-level languages to deal
consistently with asynchronous exceptions: exceptions which can happen
after any bytecode operation.  An example is KeyboardInterrupt in
Python.  It's very difficult to fully test, and leads to bugs that
are, just like thread races, very hard to reproduce, ultimately
because rather than having a fixed set of branch points to test, you
have as many branches as you have opcodes.

(By the way, this is why in the synchronous events thread my
suggestion was a function to deliver events, keeping the points where
events can be delivered precisely defined; not something like an
"allow delivery at any time" flag.)

-- 
Glenn Maynard

Received on Thursday, 30 December 2010 22:43:41 UTC