Re: Workers

On Fri, 18 Jul 2008, Andrew Fedoniouk wrote:
> >
> > 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.
> 
> Just for brevity and to make it clear for myself:
> 
> (All this is about preemptive multitasking in JS)
> 
> 1) WindowWorker is a separate instance of JavaScript VM (virtual 
> machine)
>
> 2) Such an instance is created on demand by the script running in main 
> UI thread - "initiator".
>
> 3) Communication between different JS VMs (and so with initiator) 
> happens through message queues.
>
> 4) Message queue is a FIFO list of DOM events and timer callbacks. (DOM 
> event as an object can carry various user defined sub objects. Timer 
> callback if it is a local function can carry many things too.)
> 
> Questions:
> 0) Are the statements above correct ones?

Yes.


> (why it is "window" btw?)

Because it is implemented by the Window object. For legacy reasons the 
global object is generally called 'window'. To allow easy porting of code 
to workers, we have kept the same names.


> 1) It appears that such VMs have access to the same DOM. How 
> synchronization of access to the DOM happens then?

There is no shared state. There is also currently no separate DOM access 
of any kind (not even independent DOM trees or DOMs from XHR), since 
implementations don't want to make their DOM implementations thread safe.


> 2) It appears 
> (http://www.whatwg.org/specs/web-workers/current-work/#processing) as 
> all VMs are capable to share other objects like opened databases. What 
> about synchronization of method calls?

The database APIs are transactional.


> 3) It is not clear how Workers receive DOM events and which ones by the 
> way?

Well they can fire whatever DOM events they want on themselves. For 
communication through the channel messaging system the events fired by 
message ports are the ones used to communicate; see:

   http://www.whatwg.org/specs/web-apps/current-work/#channel


> 4) It is not clear how messaging happens between different threads (JS 
> VMs). Say how following can be accomplished:
> 
> script on the page (main UI thread) ---------------
> 
> var message = { type: "simple"; data: 28; }
> var some_thread = new Thread("script.url");
>     some_thread.port.post( message );
> 
> worker ---------------
> 
> function do_something_with(message) {  ... }
> self.port.onMessageArrived( do_something_with ) ; // event alike asynchronous
> thing
> 
> //-- or is it like this ---
> 
> var message = waitUntilNextMessage(); // blocking function.
> do_something_with(message);
> 
> ?

// script on the page (main UI thread)
var some_thread = createWorker("script.url");
some_thread.onload = function () {
   some_thread.postMessage("simple 28");
};

// worker
onconnect = function (o) {
  o.messagePort.onmessage = function (e) {
    do_something_with(o.messagePort, e.message);
  };
};


> It really makes sense to provide sample JS code of how typical Worker 
> script looks like. Will help to understand all this better.

Absolutely, I'll be adding detailed examples to everything in HTML5 once 
the spec is more stable.

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

Received on Friday, 18 July 2008 21:26:09 UTC