[webkit-dev] Testing worker lifecycle

[Drew Wilson]

On Thu, Jun 25, 2009 at 2:33 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jun 25, 2009, at 2:27 PM, Drew Wilson wrote:
>
>  (resending to a wider audience - apologies to those of you who receive
>> this twice)
>> Hi all,
>>
>> The HTML5 worker spec has changed significantly from its earlier
>> incarnations, in that it's no longer externally visible whether a given
>> worker thread has shut down or not (there are no more close events surfaced
>> on the Worker).
>>
>
> What's the motivation for this particular change?
>

Primarily to avoid requiring specific GC behavior in the HTML5 spec. If you
expose when a worker has shut down, then for compatibility reasons you need
to try to make all user agents behave identically wrt garbage collection and
reachability, which puts an unnecessary burden on implementors. We've also
removed things like MessagePort.active as well as throwing exceptions if you
try to post a MessagePort that's been closed, for similar reasons. All of
this is motivated by the fact that it's prohibitively difficult to determine
cross-thread/cross-process reachability.


>
>
>  This means that there's not currently a good way to write tests to verify
>> that workers are actually shutting down when they are unreachable/idle. Do
>> you guys have any ideas about how to address this?
>>
>
> One obvious way would be to add a nonstandard equivalent to the "close"
> event ("webkitClose"). The downside is that this would be exposed to Web
> content.
>

Exactly, which I'd like to avoid for the reasons mentioned above.


>
>
>
>> One idea I had would be to expose a WorkerController for layout tests,
>> similar to GCController - the WorkerController could expose a numWorkers
>> attribute which is incremented/decremented as worker threads startup/exit. I
>> haven't started looking into how this would be done, but I figured I'd ask
>> you guys if this was a good approach or if there's a cleaner way to test
>> these cases.
>>
>
> That's also possible, the downside of this approach would be that the tests
> wouldn't work in a normal browser that doesn't have the special
> DumpRenderTree APIs.


Indeed. That feels kind of lame, but the current alternative (no tests at
all) seems bad too.


>
>
>  - Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090625/7e066209/attachment.html>