[Webkit-unassigned] [Bug 132229] Coalesce responses on network process side

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Apr 30 01:20:54 PDT 2014


Antti Koivisto <koivisto at iki.fi> changed:

           What    |Removed                     |Added
                 CC|                            |sam at webkit.org

--- Comment #24 from Antti Koivisto <koivisto at iki.fi>  2014-04-30 01:21:13 PST ---
(In reply to comment #23)
> This is certainly interesting - there aren't a lot of messages sent, after all. Recently I debugged a problem by printing out all messages between all WebKit processes while loading a complex web page, and that was still very manageable.

It is just that the "IPC is free" theory is wrong. Note that there is also context switch overhead that doesn't show up in profiles.

> I wonder how many of these messages are didReceiveData ones - perhaps coalescing only these would be sufficient. It has certainly come up before that parsing data in smaller chunks (due to CFNetworks callbacks never being blocked) might cause trouble, although I don't think that's we've ever seen a confirmation.

This approach is strictly better since it coalesces more messages, at least 3->1 in all non-disk-cache cases.

Generally there is no reason to keep our internal IPC looking like the external webkit API.

> This makes me think about something that this patch appears to regress. How do we handle Content-Disposition: attachment for subresources? A client needs to make a decision in didReceiveResponse before the delegate call even returns. In fact, the API contract is for the client to get callbacks right away, although I'm not sure if that's readily observable for anything but downloads.

I don't understand the mechanism this patch would affect "Content-Disposition: attachment" handling. The client is still free to make decisions in didReceiveResponse. But we can certainly disable coalescing in that case if it is a concern.

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list