[whatwg] Workers and queue of events

On Tue, 18 Nov 2008, Dmitry Titov wrote:
>
> Pages communicate with their workers (dedicated) via queue of 
> events.
>
> What happens if the queue gets more and more events queued (as a result 
> of postMessage or timer callbacks) and the worker thread does not 
> consume them fast enough?
> 
>    - setInterval can skip posting a callback if the previously posted one
>    was not yet consumed.
>    - setTimeout is probably ok as it is but if the worker script adds them
>    in a loop it can be a problem.
>    - postMessage could somehow indicate a queue overflow and ignore the
>    attempt to post a message if the queue length exceeds some specific
>    threshold.
> 
> Basically, the queue probably should have a limit on it and once the 
> limit is reached, the queue-based operations should start to fail, 
> optionally with some indication.

As the spec says: "User agents may impose implementation-specific limits 
on otherwise unconstrained inputs, e.g. to prevent denial of service 
attacks, to guard against running out of memory, or to work around 
platform-specific limitations."


On Tue, 18 Nov 2008, Dmitry Titov wrote:
>
> It does seem like OOM indeed but it may be different because with 
> multiple threads it's much easier to get into effects like this, you 
> don't need to allocate a lot of objects.For example, lets say there is 
> something like this:
> 
> function computeStuff() { ... }  // takes 100ms to compute stuff
> setInterval(computeStuff, 10);
> 
> in normal situation, the single-threaded JS implementation would not 
> normally post another callback until the computeStuff() returns - since 
> timers are not checked nor timer events fetched until the previous 
> callback yields control, it's hard to implement this in a way that can 
> produce out-of-memory. In multithreaded implementation (with Workers) 
> the main thread that processes timers could stuff the Worker's queue at 
> 10ms intervals while the Worker will process those callbacks at 100ms 
> interval.
> 
> Same can happen with postMessage. On a fast computer it will just work, 
> on a slow it can go out of memory.
> 
> Not sure if it should be reflected in the spec itself though...

I don't know what we can say beyond what we already say, really.


On Wed, 19 Nov 2008, Robert O'Callahan wrote:
> 
> You're not allocating JS objects but you are allocating event objects 
> internally, and everything's going to work fine until you actually do 
> hit OOM. So I think you should treat it like any other OOM and it should 
> not be exposed to the Web author in any special way.

I agree.


On Tue, 18 Nov 2008, Dmitry Titov wrote:
>
> SharedWorkers potentially would run cross-process. IPC can stop/stuck 
> for many reasons, taret process can die in the midflight (killed by the 
> user from TaskManager for example). I guess in this case 
> Worker.postMessage() could still just return as if everything is ok, but 
> nothing would happen. Is it the right behavior?

Yeah. That's what happens when you postMessage() to an unentangled port 
too.


On Tue, 18 Nov 2008, Jonas Sicking wrote:
> 
> And if it becomes a problem we might in a future version be able to add 
> something like a 'messagepostfailed' event that is fired on the sending 
> port in case a message failed to reach its target for one reason or 
> another.

Right.


On Wed, 19 Nov 2008, Robert O'Callahan wrote:
> 
> I don't think that would be useful. What if the message reaches the 
> target but the target dies while the message is queued? Or it dies after 
> executing the first JS statement in the message handler?

Indeed.


> If I was implementing workers in their own processes, I'd be tempted to 
> make abnormal termination of the worker fatal to any Web page that was 
> aware of the existence of the worker. The principle of "if you can't 
> follow the spec, destroy the evidence so no-one can prove it".

Agreed.

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

Received on Monday, 15 December 2008 22:38:04 UTC