[webkit-dev] SharedScript/Worker and multiprocess browsers

Darin Fisher darin at chromium.org
Mon Nov 30 20:28:12 PST 2009

On Mon, Nov 30, 2009 at 5:45 PM, Peter Kasting <pkasting at google.com> wrote:

> On Mon, Nov 30, 2009 at 5:05 PM, Oliver Hunt <oliver at apple.com> wrote:
>> It is wrong to design an API based on architectural decisions of your
>> existing browser -- you should be making decisions based on what the
>> developers actually need.  Being hard for the browser to implement is a
>> secondary concern next to being hard for the end developer to use.
> This is an aside that concerns the general point above, not GlobalScript
> etc. specifically.
> I agree that in general we should push complexity towards the UA vendor and
> away from the web author, but your statement is too sweeping.  It is
> certainly relevant to consider the concept of multiprocess browsers when
> designing APIs.  Failing to take that into account at all can lead to APIs
> which make process separation outright impossible.  It's one thing to make
> implementation somewhat trickier for UA vendors, it's another thing entirely
> to completely eliminate whole categories of browser architectures in the
> name of developer simplicity.
> To give an example of "poor foresight in a spec" from the past, synchronous
> XHR is convenient for developers in certain circumstances, but I think all
> implementors recognize that it was a mistake to specify and we'd be better
> off without it.  For a ridiculous hypothetical example, we wouldn't spec an
> API that required UAs to solve the halting problem.  Developer need and
> convenience should certainly be the prime motivator of APIs, but not the
> only motivator.
> PK


"Being hard for the browser to implement is a secondary concern"

^^^ Oliver, you are ignoring my assertion that it is not just about
simplicity of implementation but also about the poor performance of the
result.  You negate much of the performance benefits of a multi-threaded
architecture if you force the threads to run interlocked (required to
enforce run-to-completion semantics).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/c7d7ced6/attachment.html>

More information about the webkit-dev mailing list