[webkit-dev] Issues with WebWorkers that may block Safari support

[Drew Wilson]

Hi all,

There have been various side discussions regarding the stability/viability
of Workers and SharedWorkers, and I wanted to make sure we understand all of
the concerns, since as far as I know there isn't any one person who has been
privy to all of the conversations (or maybe it's just me that's been out of
the loop :). So I'll enumerate the issues I'm aware of below, and people can
chime in on any that I've missed that may impact the ability to ship these
features, and we can figure out how to get them addressed ASAP.

1) worker-lifecycle.html fails intermittently (
https://bugs.webkit.org/show_bug.cgi?id=29344)

The original report doesn't seem to be a true worker failure, but rather an
artifact of the way GC works in JSC. Since JSC uses conservative GC, it's
quite possible for the VM to think that there's a dangling reference to a
Worker even though there isn't actually one, and that seems to be what's
happening here (workers would get shutdown when the parent document closes
regardless, so there's no actual leak). Unless someone has some idea of how
to make this GC more deterministic, my recommendation would be to just
disable this test and close this bug, since seemingly it's the test itself
that is not reliable, not the underlying worker code.

That said, there's a sporadic worker crash that seems to have started
happening in the last week or so which I believe is a different issue -
eseidel has glommed that crash onto the same bug, and I think we should move
that to its own issue and see if we can collect more information about it.

2) SharedWorkers proxy their network access to a parent document (no bug for
this currently)

The result of this is the application can get a network error if the user
has multiple windows open that are using the same SharedWorker, then closes
the parent document that is acting as a network proxy while a network
request is in progress. While this is something that would need to change
eventually in order to properly support exposing the appcache APIs to
SharedWorker context, it doesn't seem like this would be any kind of ship
blocker. Any robust application would need to deal with sporadic network
hiccups anyway by retrying, and in practice this situation will almost never
be encountered in the field. Perhaps people have other concerns that make
this a ship blocker?

3) Potential race conditions with Document.postTask() (
https://bugs.webkit.org/show_bug.cgi?id=31633)

I've suggested a simple solution to the potential race condition with
SharedWorkers in the bug. I'd be interested in hearing whether people think
it's a good approach or not - if so, I'm happy to submit a patch for review
in short order. There's still the question as to whether dispatching tasks
on a detached Document is OK or not, but I'm assuming it is (since that's
what Dedicated workers have always done).

Are there other issues we should be addressing as a high priority?

-atw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091204/6daf88a3/attachment.html>