Bug 132144 – Don't use DispatchMessageEvenWhenWaitingForSyncReply for messages from NetworkProcess

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Alexey Proskuryakov]

void AsynchronousNetworkLoaderClient::willSendRequest(NetworkResourceLoader* loader, ResourceRequest& request, const ResourceResponse& redirectResponse)
{
    // This message is DispatchMessageEvenWhenWaitingForSyncReply to avoid a situation where the NetworkProcess is deadlocked
    // waiting for 6 connections to complete while the WebProcess is waiting for a 7th (Synchronous XHR) to complete.
    loader->sendAbortingOnFailure(Messages::WebResourceLoader::WillSendRequest(request, redirectResponse), IPC::DispatchMessageEvenWhenWaitingForSyncReply);
}


There are several confusing things here:

1. If we send messages with IPC::DispatchMessageEvenWhenWaitingForSyncReply from NetworkProcess, they can be handled during sync XHR, causing undesirable reentrancy. That's dangerous.

2. But IPC::DispatchMessageEvenWhenWaitingForSyncReply doesn't really work in NetworkProcess, because the connection uses setOnlySendMessagesAsDispatchWhenWaitingForSyncReplyWhenProcessingSuchAMessage(true), so the flag is usually ignored. When it's not ignored, see the above.

3. The comment claims that we need this because otherwise we would have a deadlock. It's not accurate - we would happily load sync requests even if there are 6 async ones stuck. We disable connection limits for sync requests, even when pipelining is not in use.

This is probably difficult to reproduce in practice.

[Alexey Proskuryakov]

Created attachment 230105 [details]
proposed patch

[WebKit Commit Bot]

Comment on attachment 230105 [details]
proposed patch

Clearing flags on attachment: 230105

Committed r167866: <http://trac.webkit.org/changeset/167866>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.