[webkit-dev] Parallel JavaScript: Why a separate ParallelArray types
Ian Hickson
ian at hixie.ch
Fri Apr 12 23:56:58 PDT 2013
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.
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.
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,
2. Every Web author is potentially a bumbling fool.
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).
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. `._.-(,_..'--(,_..'`-.;.'
More information about the webkit-dev
mailing list