W3C home > Mailing lists > Public > public-html@w3.org > July 2008

Re: Workers

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 10 Jul 2008 02:13:49 -0700
Cc: 'Ian Hickson' <ian@hixie.ch>, public-html@w3.org
Message-Id: <F99F54F9-6EF9-41E6-984A-534049FF479F@apple.com>
To: Justin James <j_james@mindspring.com>


On Jul 9, 2008, at 9:18 PM, Justin James wrote:

>
> I have some questions/comments/concerns on this:
>
> 1) The HTML 5 spec states that the DOM is not ECMAScript-only, but
> acknowledges that no common browser is shipping with, say, Ruby or  
> Lisp as a
> client-side scripting system. However, the current draft states that  
> it is
> ECMAScript-only. How do we resolve this conflict?
>
> 2) No mention of inter-thread communications (such as semaphores) or  
> locking
> mechanisms (spin locks, monitor, mutex, etc.). This is critical.

Workers are designed to be shared-nothing message-passing threads (in  
the style of Erlang), not shared-memory threads a la C or Java, so  
there is no need for locking primitives and your concerns about  
deadlocks and the difficulty of multithreaded code do not apply.

  - Maciej

>
>
> 3) I know it's a rough outline of the form that the spec will take,  
> but it
> must have mechanisms for the UA to do things like force the breaking  
> of a
> deadlock. Without this, it is trivial for a poorly written piece of  
> code to
> absolutely cripple the browser quite by accident, and pass testing  
> 99.9999%
> of the time.
>
> 4) Multithreaded code is *insanely* difficult for the average  
> programmer to
> write, debug, and test. If we can't get the typical Web developer to  
> spit
> out valid HTML, do we *really* want to enable them to inflict  
> multithreaded
> code on their users? Of course, my hope is that few developers will  
> actually
> use it, just as threads have been available to desktop app  
> developers for a
> long time, but only a small fraction of developers actually use them.
>
> 5) Threading is something that should be specified at the language  
> level
> nearly all of the time. How/why are we now trying to implement it as  
> part of
> the HTML 5 spec? I would think that adding thread support to  
> ECMAScript is
> the ECMAScript group's responsibility.
>
> 6) I have a sizable amount of experience on the development end of  
> writing
> multithreaded applications. What do I need to do to actively  
> participate in
> the development of this spec? It's a topic that I am particularly  
> interested
> in.
>
> Thanks!
>
> J.Ja
>
>> -----Original Message-----
>> From: public-html-request@w3.org [mailto:public-html- 
>> request@w3.org] On
>> Behalf Of Ian Hickson
>> Sent: Wednesday, July 09, 2008 9:30 PM
>> To: public-html@w3.org
>> Subject: Workers
>>
>>
>>
>> Based on popular demand (and threats that without a spec
>> implementations
>> would proceed regardless) I have started collecting use cases and
>> requirements for a specification for background worker scripts
>> ("threads")
>> in JavaScript:
>>
>>   http://www.whatwg.org/specs/web-workers/current-work/#requirements
>>
>> Any feedback would be greately appreciated, especially from authors
>> involved in large Web applications who would make significant use of
>> such
>> a feature, and from implementors of browsers that may support this.
>>
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.
>> fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
>> ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-
>> .;.'
>
>
Received on Thursday, 10 July 2008 09:14:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:19 GMT