Re: Workers

  
Due to popular demand, I have written a new specification for Workers:
 
   http://www.whatwg.org/specs/web-workers/current-work/


On Wed, 9 Jul 2008, Andrew Fedoniouk wrote:
> 
> Ian, as far as I understand that is primarily about network 
> communications? If yes then what is conceptually wrong with asynchronous 
> http data requests (a.k.a. AJAX) we have now?

It's about background computation, background syncing of client-side and 
server-side databases, and other such tasks.


> If it is about coroutine alike things then 'yield' feature in JS 
> probably will be enough, no?
> 
> To be short what is the motivation of js-threads?

One example from Google's stable would be separating the UI and the 
low-level networking and database access in GMail: it would be cool if 
instead of having everything running on the same thread, the UI could just 
post messages to a background thread that did all the real work.


On Thu, 10 Jul 2008, 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?

Web Workers are intended for JS only. I don't really see a conflict.


> 2) No mention of inter-thread communications (such as semaphores) or 
> locking mechanisms (spin locks, monitor, mutex, etc.). This is critical.

There's no shared state, so these are not necessary.


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

There's no way to get a deadlock, there's no shared state and the only 
communication mechanism is asynchronous.


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

I don't think this API gives the developers the rope that typical thread 
APIs provide.


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

I think this requires much tighter integration with the way HTML5 works 
than the way JS works, actually. We could probably make this API language 
neutral without much difficulty, if we really wanted to.


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

You are already actively participating. :-)

If you wish a more direct involvement in edits, you can join IRC (#whatwg 
on Freenode or #html-wg on the W3C's IRC network) and comment and advise 
on edits as they happen. You can get notifications for non-editorial edits 
as they happen by subscribing to the WHATWG user on Twitter, and can get 
notifications of _all_ edits by subscribing to the Commit-Watchers list:

   http://www.whatwg.org/mailing-list#commits


Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 18 July 2008 11:08:38 UTC