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

[Filip Pizlo]

On Apr 13, 2013, at 8:37 AM, Ian Hickson <ian at hixie.ch> wrote:

> 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.

It's even easier to abort a program that is waiting for a lock, than it is to abort a program that is stuck in a loop. 

Again, this is not a great argument against locks. 

> 
> 
>>> 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.

Same difference. I think this is overly harsh. Nobody will hold a gun to your head and force you to use threads. The bumbling fools will probably ignore it.

The situation we have now is far worse actually: to get your scripts to do useful thing you need to turn them inside-out using continuation passing style. Much of it is because every interesting API is asynchronous. Are you suggesting that continuation passing style with fully asynchronous APIa is easier to understand than threads and synchronous APIs?  I suspect that they can both be classified as hard, and both lead to people making terrible mistakes. I also suspect that threads are the easier of the two - at least that is my thinking based on memories of how hard it was for a professor to explain CPS to people. 

And even if the fool did use shared mutable state, the worst case outcome is a flaky webpage. It's not the end of the world. 

> 
> 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.

I don't think that shared mutable state is that bad for bumbling fools, particularly when compared to the status quo.

But on a higher level, I think that the bumbling fool argument ignores the level of sophistication that web developers are already capable of achieving.  The stuff people build with web technology never ceases to amaze me.  The web platform already has its warts, and people already find ways around them; they do so because on the whole, these are smart people.  Giving them a useful too that is already available and well-understood in other languages can only be a good thing.

I personally do not like thinking of the people who use the stuff I build as fools; I don't think it's constructive.

-Filip

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