[webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

[Ian Hickson]

On Sat, 13 Apr 2013, Filip Pizlo wrote:
> > 
> > Actually, you can't. We very specifically designed workers (and even 
> > more importantly the API on the main thread) so that you cannot block 
> > on waiting for a message.
> 
> You can also design lock APIs this way:

Sure. Lots of APIs do it this way.


> Anyway, apologies for getting into semantics, but web workers don't 
> eliminate "deadlock" - they just ensure that the main thread doesn't 
> block if it happens.

They do eliminate deadlock in the sense of two threads that cannot receive 
any messages because they are blocked on each other. They don't eliminate 
"soft" deadlock in the sense of an application that no longer progresses 
because it's waiting for a message that'll never come, but that's no worse 
than many kinds of logic errors where code stops progressing.


> > Certainly you can have a logic error that causes the application to 
> > stop progressing, but you cannot have a deadlock that blocks the event 
> > loop of the main thread.
> 
> You can already block the main thread by having a runaway script, so 
> this could be viewed as an overly harsh goal when picking concurrency 
> models.

Actually you can't have runaway scripts on the main thread on the Web. 
Browsers will just abort the scripts after a brief timeout.


> > Web APIs have different constraints than non-Web platforms that may 
> > help explain why the Web sometimes seems dumb from the perspective of 
> > professional programers or computer scientists. Specifically, the Web 
> > platform's design assumes the following:
> > 
> > 1. Every Web author is potentially hostile and very clever,
> 
> Threads do not make the Web author any more hostile, but I appreciate 
> that this should be a serious goal.

Right, this aspect is not especially relevant to Web workers. I included 
it just for completeness because these two reasons really do underlie most 
of the decisions that people coming from other platforms find weird.


> > 2. Every Web author is potentially a bumbling fool.
> 
> I don't disagree with this, but I'm not sure that I'm convinced that the 
> application of this ethos implies that we cannot have locks

It doesn't imply you can't have locks, it implies you can't have 
unprotected shared state.

We _can_ have shared state that can only be accessed in a safe way. 
IndexDB, for instance, allows shared state accessed from workers, because 
you can only get to the state via a transaction-like deadlock-free API.


> Responsive UI is a good argument for having concurrency, and making it 
> easier to use.

So long as it doesn't sacrifice the two higher priorities of making the 
API safe against attackers, and being simple enough to be used by bumbling 
fools, sure.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'