W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2009

[whatwg] Global Script proposal.

From: Mike Shaver <mike.shaver@gmail.com>
Date: Mon, 31 Aug 2009 15:48:43 -0400
Message-ID: <cc092ba00908311248s6d666144tdec6f0c652255d01@mail.gmail.com>
On Sat, Aug 29, 2009 at 5:40 PM, Ian Hickson<ian at hixie.ch> wrote:
> Furthermore, consider performance going forward. CPUs have pretty much
> gotten as fast as they're getting -- all further progress is going to be
> in making multithreaded applications that use as many CPUs as possible. We
> should actively moving away from single-threaded designs towards
> multithreaded designs. A shared global script is firmly in the old way of
> doing things, and won't scale going forward.

Multi-threaded or multi-process, at least.  Most web developers are
quite familiar with multi-process development, where each process has
a single flow of control, since that's what the browser/server
interaction is.  The multiple server-side processes that end up
involved over the course of the user's interaction do need to share
state with each other, and preserving blocking semantics for accessing
such state makes the programs much simpler to reason about given
today's programming languages.  Is that shared state not what the
Global Script Object would provide?  If the synchronization overhead
of manipulating it becomes undesirable to an app developer for
performance reasons, they can use a worker with local state and an
event mechanism or some such; that's largely what people do on the
server side as well.

> Granted,
> programmers today don't want to use threads -- but, well, tough. All
> indications are that that's what the programming model of the next few
> decades is going to be; now is the time to move that way. We shouldn't be
> adding features that actually move us back to the single-threaded world.

I disagree that explicit use of threads is the programming model of
the next few decades.  We are seeing more and more developers eschew
shared-heap threads in favour of other techniques (f.e., task queues)
that adapt better to varying system resources and allow simpler
decomposition of the programming tasks.  Apple's Grand Central
Dispatch appears to be in this vein, though I confess I haven't
analyzed it in any significant way yet.

Mike
Received on Monday, 31 August 2009 12:48:43 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:16 UTC