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
already.
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
blocker?
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.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
