[whatwg] Web Workers

[Ryan Heise]

Drew Wilson wrote:

> Rather than trying to shoehorn concurrent functionality into Javascript (where
> many implementations don't support multi-threaded access down at the VM level
> anyway, so the obstacles to implementation seem fairly large) it seems like a
> better option is to use a different language entirely.

While I would ideally prefer to develop web games in any language of my
choosing, this seems to be the worse option in practice. It is important
to consider that many developers and browser vendors see value in
adopting standards. Javascript currently is that standard, and is the
only web programming language supported by IPhone, Android and Desktop
browsers.

It would seem a worthwhile pursuit to improve the standard in spite of
any technical obstacles, not only because engineers love technical
obstacles, but also because part of the technical obstacle is to rework
the DOM to be threadsafe. The DOM, if my understanding is correct, is
not part of the Javascript implentation itself, and so any other
scripting language that we hope to use in place of Javascript will also
limit us in terms of its threading capabilities and interaction with the
DOM until the DOM is made threadsafe.

>     There is currently no way for a program to find out how many cores
>     are present in the host system. 
>
> Not sure if any conclusions were drawn - I think we may have kept this
> open as an option for v2 of the spec.

Thanks, that is good news to hear.


Boris Zbarsky wrote:

> On 7/21/10 4:11 PM, Ryan Heise wrote:
> 
> > Note that things might have been different had Javascript been a
> > purely functional language. If this were the case, then there would
> > be much safer and more efficient alternatives to making whole copies
> > of data that could be implemented under the hood.
> 
> Why does this require JS to be purely functional?  There's already
> work happening in this direction, though obviously arbitrary object
> graphs are hard due to the mutability.
> 
> If we eliminate mutability (e.g. sealing the objects in the relevant
> graph), then the memory could in fact be shared instead of copied,
> right?

Yes, but this is not the whole story. Before I go on, let me quickly
suggest something that may help with functional-style VM optimisations
in the future, if there is a decision to pursue this. C# has the ability
to distinguish between structs which represent values, and classes which
represent references. If Javascript introduced similar syntax, then the
problem of dealing with arbitrary object graphs could be made easier.
Along similar lines, other syntax can also be added to the language to
declare certain objects as immutable, and certain functions as being
bing pure (lacking side effects). This can be used by the VM to do
various functional-style optimisations in addition to sharing read-only
memory.

But in relation to the main point, the whole story is that these data
heavy algorithms very rarely have merely readonly requirements on
memory, UNLESS you go to the extreme and support functional-style
programming in its entirety. Take, for example, a sorting algorithm. In
the imperative style of programming, any implementation, even parrallel,
will need to not only do many read operations, but also many write
operations. It is not unless you completely rework your code into a
purely functional style that it will be possible to implement a sorting
algorithm using immutable data structures, and the efficiency will be
terrible unless the VM also does heavy optimisations in light of the
functional style of programming being used. Even still, it is well known
that as far as sorting algorithms and other algorithms involving heavy
data manipulation is concerned, the functional implementation (even
optimised) will be nowhere near the performance of the imperative
implementation with in-place update.

> >For all of the reasons above, I would like to see something like threads
> >in Javascript.
> 
> Note that some current JS engines support this (though not in a web
> context at the moment).
> 
> Note also that said engines are removing said support for various
> reasons (performance penalties are a large part of it).

Clearly, it has been shown possible to implement threads efficiently in
other languages, and so I do wonder how the decision processes of those
VM developers might be affected if the spec where changed to mandate
threads.

> >As a final thought, I would like to say that it is actually possible to
> >detect deadlock conditions at runtime and immediately throw an exception
> >rather than simply hang the web browser.
> 
> At what performance cost in the typical case, though?

A cheap way is to rule out the possibility to acquire locks in a
circular order. The performance cost will really be negligible. Rather
than allowing the programmer to arbitrarily create locks, the API could
provide a means to obtain a reference to (as distinct from aquire!)
locks from a system-defined sequence of locks. As distinct from this,
Java-like synchronized blocks can be used to aquire (i.e. actually lock)
and release these locks. The system-defined sequence of locks will have
associated with it the position number of the most recently acquired
(and still held) lock. Whenever aquiring a lock, the performance cost
will be this: an if statement will check if the position number of the
presently requested lock is greater than the position number of the most
recently aquired lock. If it is not, throw an exception. (As in Java,
you would also want to allow a thread to re-aquire a lock that it
already holds, but I am not addressing that in my explanation).

-- 
Ryan Heise