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

Re: Workers

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 19 Jul 2008 05:14:28 +0000 (UTC)
To: Andrew Fedoniouk <news@terrainformatica.com>
Cc: public-html@w3.org
Message-ID: <Pine.LNX.4.62.0807190501160.12994@hixie.dreamhostps.com>

On Fri, 18 Jul 2008, Andrew Fedoniouk wrote:
> 
> So the thread will have that 'window'/'self' object in global namespace, 
> correct?
> 
> What about window.document, window.history, etc. then?

What is available in the Worker thread is defined in:

   http://www.whatwg.org/specs/web-workers/current-work/#apis-available


> > > 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.
> 
> It appears as there is some shared state - the DOM per se.
> Almost any object in DOM and Event modules has references
> to window or document. MessageEvent for example has field 'source'.

It is always null when used with MessagePort objects. As far as I'm aware 
there's no way to get to a Document object in a WindowWorker context. 
That's certainly the intent; let me know if I left any ways in by mistake.


> > > 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.
> 
> Sorry but that is not clear.
> Terms "DB transactional" and "multithread DB" are orthogonal. There are a lot
> of DB engines that support transactions but do not support multithreading.
> SQLite is such an engine for example.

On the backend it is certainly the case that implementations will have to 
be very careful in their coding. This is independent of the Workers spec, 
though.


> > > 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
> 
> What exactly is the DOM event? This one: 
> http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-Event ?
> 
> What about such attribute as event.target? It is DOM object usually. Or 
> event.source? If yes then what prevents Worker to store it and to 
> manipulate DOM or window from second thread?

event.target is whatever the Event it. In the case of a MessagePort, the 
target is the MessagePort. event.source is always null. I don't really 
understand what you are asking here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 19 July 2008 05:15:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:56 UTC