[Webkit-unassigned] [Bug 158239] Notify client immediately if network session doesn't exist for a synchronous XHR load.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=158239

--- Comment #13 from Yongjun Zhang <yongjun_zhang at apple.com> ---
(In reply to comment #12)
> Comment on attachment 280269 [details]
> V3: notify the client asynchronously.
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=280269&action=review
> 
> > Source/WebKit2/NetworkProcess/NetworkLoad.cpp:64
> > +        RunLoop::main().dispatch([this, url = parameters.request.url()] {
> > +            didCompleteWithError(internalError(url));
> > +        });
> 
> This is a super nit pick, and the first time I've ever suggested it...
> 
> But we've been looking at all of our lambda usage lately, and going over
> things like "RunLoop::dispatch" and "callOnMainThread" with a fine toothed
> comb. We've found a number of thread safety issues.
> 
> At a glance, this looks like a potential thread safety issue, because it's
> unsafe to send a URL across threads without making an isolatedCopy() of it
> first.

Yes, I had the same concern at first, but I convinced myself it won't be an issue - it looks like we expected NetworkLoad to always work on main thread (e.g., we assert this in couple of places). 
> 
> Of course this isn't *actually* a thread safety issue because it's not cross
> thread - RunLoop::main() happens to also be the current RunLoop.
> 
> If the dispatch was instead "RunLoop::current().dispatch(...)", then I
> wouldn't even have considered it a potential thread safety issue.
> 
> If you'd like to make that change, that'd be nice. I haven't thought about
> it a lot yet, but I think that's what we should do going forward and will
> likely be discussing with a larger audience soon.

Sure thing! I will make this change before landing.
> 
> r+ either way.

Thank you for the review!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160602/0a07c567/attachment-0001.html>