<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [SOUP] Network process crash in WebKit::CustomProtocolManagerImpl::didFailWithError"
   href="https://bugs.webkit.org/show_bug.cgi?id=165082#c15">Comment # 15</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [SOUP] Network process crash in WebKit::CustomProtocolManagerImpl::didFailWithError"
   href="https://bugs.webkit.org/show_bug.cgi?id=165082">bug 165082</a>
              from <span class="vcard"><a class="email" href="mailto:aestes&#64;apple.com" title="Andy Estes &lt;aestes&#64;apple.com&gt;"> <span class="fn">Andy Estes</span></a>
</span></b>
        <pre>(In reply to <a href="show_bug.cgi?id=165082#c12">comment #12</a>)
<span class="quote">&gt; I just verified that the API test added in r149194 passes on Mac with
&gt; CustomProtocolManager being a MessageReceiver instead of a
&gt; WorkQueueMessageReceiver.  I did this with and without NetworkSession, but
&gt; with NetworkSession also requires changing globalCustomProtocolManager() to
&gt; be a std::unique_ptr and setCustomProtocolManager to call the
&gt; std::unique_ptr constructor explicitly.
&gt; Let's give it a shot and see what Andy says.  We don't have many clients
&gt; using WebKit2's CustomProtocolManager because it's not public API, so it's
&gt; possible we have a similar thread safety issue on Mac and just don't get a
&gt; lot of stack traces.</span >

It looks like synchronous XHR is now handled by sending a delayed synchronous CoreIPC message from the Web process to the Networking process. The networking process handles the load asynchronously and replies to the Web process when finished.

Since there is no longer a nested, non-common-mode run loop, there's no longer a need for a WorkQueue in CustomProtocolManager.

At least on Mac, there is still a need for some synchronization between the main thread and the thread that NSURLProtocol methods are called on, but that shouldn't affect the Soup implementation.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>