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

[Filip Pizlo]

On Apr 12, 2013, at 11:56 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 12 Apr 2013, Filip Pizlo wrote:
>> 
>> There is a possibility of deadlock.  You can have one task waiting for a 
>> message from another, and that other waiting for a message from the 
>> first.
> 
> 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:

lock.acquireAsynchronously(function() { … do things … });

It's less attractive to me, but I think that this is similar to other programming models already out there.

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.  It's still possible for the web app itself to get into a deadlocked state even if the UI thread is still receptive to events.  There is a difference here.  Both locks and message queues can be designed around asynchrony.  With asynchrony, the "deadlock" of locks becomes no more dangerous than the "deadlock" of your message handler never firing even though you expected it to.  This is what I meant by deadlock being a feature of both locks and message-passing: both are equally predisposed to someone stalling, and in both cases you can avert the stall in the programming model by using asynchrony instead of blocking operations.

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

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

> 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, particularly since their acquisition on the main thread can be asynchronous just like the message passing of workers is.

> 
> Most platforms instead assume that their programmers are mostly benign and 
> that their programmers are mostly competent.
> 
> These two assumptions are the main reason for almost every "weird" 
> decision the Web platform has.
> 
> If you want to do highly efficient computation, the Web is probably not 
> going to be the best platform to use to do it, because computational 
> performance has never been near the top of the priority list. Responsive 
> UI is a high priority, security (resilience to hostile author code) is a 
> high priority, fault tolerance has been a high priority (gracefully 
> handling author mistakes), the ability to have code work uniformly across 
> a wide variety of devices and platforms has been a high priority (most of 
> the time, though we stumbled a bit with mobile input models). 

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

> 
> If you want to do intensive computation, the answer has traditionally been 
> "do it on the server".
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130413/516cd7cf/attachment-0001.html>