Re: [webkit-dev] NetworkProcess / NetworkThread in the UIProcess
On 02/12/2013 04:51 PM, Zeno Albisser wrote: Hi, I have been looking into the NetworkProcess code that has recently been added to WebKit2. For Qt we are considering moving all the networking into a separate thread within the UIProcess. Do you guys think that the NetworkProcess code could be designed in a way to allow running in a separate thread of the UIProcess instead of in a separate process? We are convinced that this design would be a very good fit for our needs. Also in the light of the currently ongoing effort of cleaning up our Qt-bits and pieces in WebKit2. After a quick look it seems to me that this could be achieved with fairly minor modifications: * Instead of relying on RunLoop::main() within NetworkProcess, a different function would need to be introduced to retrieve a networking RunLoop. This would allow to process networking related events in the network thread. Depending on the platform, this could of course return a pointer to the main-RunLoop, for the cases where networking is indeed executed in a separate process. * Splitting the NetworkProcess class in two pieces. The child process and IPC setup remaining in NetworkProcess, and the actual networking code in a separate class (e.g. called NetworkThread). Provided the IPC (between threads in our case) would be setup upfront this would allow running the code provided by NetworkThread in a separate thread. You also need IPC because the NetworkProcess serves the needs of the web process. Could you describe why a network thread in the UI process fit your needs bettter? Is it to support API's related to networking or does it have other advantages? -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] NetworkProcess / NetworkThread in the UIProcess
On Tue, Feb 12, 2013 at 5:01 PM, Balazs Kelemen kbal...@webkit.org wrote: You also need IPC because the NetworkProcess serves the needs of the web process. Could you describe why a network thread in the UI process fit your needs bettter? Is it to support API's related to networking or does it have other advantages? Yes, that was slightly ambiguous. Let me rephrase that. Currently the IPC for the NetworkProcess is setup by ChildProcess::initialize(). Since we would not need to create a whole new process in our case, we would just spin of a thread and create the appropriate IPC connections ourselves. That could be an implementation detail of our NetworkThread implementation. For prototyping i even reused the whole ChildProcess code with a few minor changes. But it would feel wrong to have instances of ChildProcess in something that is a thread of the same process. One of the main advantages of having networking in the UIProcess for our port is, that we could support some features such as Application URL Schemes without going through the WebKit2 API. This is a very Qt specific use case, that IMHO does not fit very nicely into the rest of the WebKit2 API. It is Qt specific because Qt makes heavy use of qrc files to embed content. And Application URL Schemes was the solution to allow for qrc content in a QQuickWebView. - Zeno ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] NetworkProcess / NetworkThread in the UIProcess
On Feb 12, 2013, at 8:28 AM, Zeno Albisser z...@webkit.org wrote: On Tue, Feb 12, 2013 at 5:01 PM, Balazs Kelemen kbal...@webkit.org wrote: You also need IPC because the NetworkProcess serves the needs of the web process. Could you describe why a network thread in the UI process fit your needs bettter? Is it to support API's related to networking or does it have other advantages? Yes, that was slightly ambiguous. Let me rephrase that. Currently the IPC for the NetworkProcess is setup by ChildProcess::initialize(). Since we would not need to create a whole new process in our case, we would just spin of a thread and create the appropriate IPC connections ourselves. That could be an implementation detail of our NetworkThread implementation. For prototyping i even reused the whole ChildProcess code with a few minor changes. But it would feel wrong to have instances of ChildProcess in something that is a thread of the same process. One of the main advantages of having networking in the UIProcess for our port is, that we could support some features such as Application URL Schemes without going through the WebKit2 API. This is a very Qt specific use case, that IMHO does not fit very nicely into the rest of the WebKit2 API. It is Qt specific because Qt makes heavy use of qrc files to embed content. And Application URL Schemes was the solution to allow for qrc content in a QQuickWebView. Is this just for the qrc URL scheme specifically? If so, why not just teach the NetworkProcess how to handle qrc:? Using a thread instead of a process sounds like overkill just to solve that one problem. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] NetworkProcess / NetworkThread in the UIProcess
On Feb 12, 2013, at 12:00 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 12, 2013, at 8:28 AM, Zeno Albisser z...@webkit.org wrote: On Tue, Feb 12, 2013 at 5:01 PM, Balazs Kelemen kbal...@webkit.org wrote: You also need IPC because the NetworkProcess serves the needs of the web process. Could you describe why a network thread in the UI process fit your needs bettter? Is it to support API's related to networking or does it have other advantages? Yes, that was slightly ambiguous. Let me rephrase that. Currently the IPC for the NetworkProcess is setup by ChildProcess::initialize(). Since we would not need to create a whole new process in our case, we would just spin of a thread and create the appropriate IPC connections ourselves. That could be an implementation detail of our NetworkThread implementation. For prototyping i even reused the whole ChildProcess code with a few minor changes. But it would feel wrong to have instances of ChildProcess in something that is a thread of the same process. One of the main advantages of having networking in the UIProcess for our port is, that we could support some features such as Application URL Schemes without going through the WebKit2 API. This is a very Qt specific use case, that IMHO does not fit very nicely into the rest of the WebKit2 API. It is Qt specific because Qt makes heavy use of qrc files to embed content. And Application URL Schemes was the solution to allow for qrc content in a QQuickWebView. Is this just for the qrc URL scheme specifically? If so, why not just teach the NetworkProcess how to handle qrc:? Using a thread instead of a process sounds like overkill just to solve that one problem. We already support custom schemes on Mac by proxying the loading from the networking process to the UI process. For the Mac this is done in terms of NSURLProtocol. You could provide your own implementation of the port-specific bits of CustomProtocolManager and CustomProtocolManagerProxy. Thanks, ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] NetworkProcess / NetworkThread in the UIProcess
On Tue, Feb 12, 2013 at 12:09 PM, Brady Eidson beid...@apple.com wrote: We already support custom schemes on Mac by proxying the loading from the networking process to the UI process. I believe we do something like this for the libsoup port as well, though network process support is still young. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
