Networking process on iOS can be suspended and never exit This is for apps that use multiple WKProcessPools and sometimes deallocate a WKProcessPool that had an active Networking process. In those cases, the Networking process can be suspended instead of terminated, and once suspended it can no longer respond to further messages. Furthermore, calling RunLoop::main().stop() is not aggressive enough to actually terminate the process - _exit is bulletproof. rdar://problem/20368630
Note: The bug exists on iOS, but the fix of having the Networking process explicitly kill itself instead of implicitly noticing an IPC::Connection close is reasonable to implement cross-platform
Created attachment 253060 [details] Patch v1
Apparently big changes to ProcessThrottler in the last couple of days. Updating and fixing the build.
Created attachment 253063 [details] Patch v2
Created attachment 253067 [details] Patch v3
Comment on attachment 253067 [details] Patch v3 Sam, Gavin, and I looked at this in person and came up with a plan for even more changes. Removing r?
Created attachment 253235 [details] New patch v1
Comment on attachment 253235 [details] New patch v1 View in context: https://bugs.webkit.org/attachment.cgi?id=253235&action=review r=me assuming you have a good way to test the new behavior > Source/WebKit2/Shared/ChildProcess.cpp:166 > + // FIXME: Subclasses of ChildProcess should all have a chance to do some explicit cleanup > + // before the process is terminated. I think this FIXME is too vague. What kinds of cleanup specifically are you thinking about? While this comment may be correct, I’m not sure we should have a FIXME here unless we know of some specific cleanup that is not being done at this time. We don’t need a FIXME about having a hook that we wouldn’t have a reason to do at this time. > Source/WebKit2/Shared/ChildProcess.h:100 > + virtual void didReceiveMessage(IPC::Connection&, IPC::MessageDecoder&) override; Can this override be private instead of protected?
(In reply to comment #8) > Comment on attachment 253235 [details] > New patch v1 > > View in context: > https://bugs.webkit.org/attachment.cgi?id=253235&action=review > > r=me assuming you have a good way to test the new behavior Indeed. > > > Source/WebKit2/Shared/ChildProcess.cpp:166 > > + // FIXME: Subclasses of ChildProcess should all have a chance to do some explicit cleanup > > + // before the process is terminated. > > I think this FIXME is too vague. What kinds of cleanup specifically are you > thinking about? While this comment may be correct, I’m not sure we should > have a FIXME here unless we know of some specific cleanup that is not being > done at this time. We don’t need a FIXME about having a hook that we > wouldn’t have a reason to do at this time. Fair enough. > > Source/WebKit2/Shared/ChildProcess.h:100 > > + virtual void didReceiveMessage(IPC::Connection&, IPC::MessageDecoder&) override; > > Can this override be private instead of protected? Nope - For now, the subclasses NetworkProcess and WebProcess call it directly from within their didReceiveMessage. We'll be working on a way to make that unnecessary in the future, at which point it can be private.
http://trac.webkit.org/changeset/184503
Fixed broken API tests in followup: http://trac.webkit.org/changeset/184514