[whatwg] Workers and queue of events

[Dmitry Titov]

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

Dmitry


On Tue, Nov 18, 2008 at 5:32 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Nov 19, 2008 at 2:08 PM, Dmitry Titov <dimich at chromium.org> wrote:
>
>> Pages communicate with their workers (dedicated) via queue of events<http://www.whatwg.org/specs/web-workers/current-work/#the-queue> .
>> 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.
>>
>
> How is this different from any other out-of-memory situation? Web APIs
> generally don't specify OOM behaviour.
>
> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081118/12adc980/attachment.htm>