[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

Brady Eidson <beidson at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #280269|review?                     |review+
              Flags|                            |

--- Comment #12 from Brady Eidson <beidson at apple.com> ---
Comment on attachment 280269
  --> https://bugs.webkit.org/attachment.cgi?id=280269
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.

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.

r+ either way.

-- 
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/99c19698/attachment-0001.html>