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

[Maciej Stachowiak]

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

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