Re: Workers

Ian Hickson wrote:
> 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
> 

Oh, thanks, missed those.

May I propose to add to the document something like this?

1. Introduction.

1.0. In brief.

[Window]Worker is a separate instance of JavaScript Virtual Machine (VM)
that runs in its own thread. Such VM is isolated from the
other scripts running on the page and other [Window]Workers.
This imply that DOM and Window objects are not accessible from code
running inside such [Window]Worker.
The only mechanism that allows [Window]Workers to communicate with each
other is to post messages through message queues. Message queue (or 
message pipe) is accessible in script through so called MessagePorts 
objects that implement abstraction of end points of such communication pipe.
-- eof --

That will define the intention and establish set of initial requirements
so readers will be prepared to accept rest of the document.


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

By Workers you introduce new entity - shared access to the same objects
local data storages and databases. I think we should mention that
DB or local storages are being manipulated in exclusive mode -
if DB is open by one Worker or main thread then it is not available
by any means in other threads. That will simplify life.

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

It is not clear why you need DOM Event in this case then.
Messages here are arbitrary JSON objects as far as I understand.
If DOM is isolated then it is isolated completely. No objects
implementing any DOM interfaces must be available. Otherwise it will be
nightmare for implementors.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Saturday, 19 July 2008 23:17:03 UTC