[webkit-dev] Issues with WebWorkers that may block Safari support
mjs at apple.com
Fri Dec 4 14:00:05 PST 2009
On Dec 4, 2009, at 1:40 PM, Drew Wilson wrote:
> 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.
For what it's worth, we'd likely consider a resolution to this bug a
blocker to shipping the next Safari release, but we would not consider
disabling dedicated Workers as a solution, since we have shipped them
If this bug could be shown to be an error in the test and
inappropriate dependence on GC, that would be a satisfactory
resolution. However, the sporadic failure here is a at least sometimes
a crash. A crash definitely indicates a bug in WebKit, not in the
test, even if the test itself is also flawed. Therefore, I would not
consider disabling the test a solution until we have at least
addressed the crash.
> 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
I don't believe we consider this a ship blocker. Though we did discuss
it at the same time as the other two items on the list.
> 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?
This one would probably be a ship blocker. We would consider disabling
SharedWorkers to ship if that addressed the issue.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev