Re: [webkit-dev] Multiprocess networking in WebKit
On Dec 4, 2012, at 12:36 PM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Tuesday 04 December 2012, Adam Barth wrote: There's been a somewhat fragmented discussion across webkit-dev and various bugs about how we ought to approach multiprocess networking in WebKit. In an attempt to organize my thoughts, I wrote up a short design document that compares various approaches: https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD 4fQY/edit ... About the network process, I would just like to suggest not limiting it to one, not even to begin with. There is not much simplicity or efficiency to be gained by keeping all network request in the same process, and extra processes could be used for faster responses and increased security. I haven't had the chance to read Adam's document yet. I disagree with your notion that a single Network Process doesn't much efficiency to be gained. In a world with multiple web content processes it is important to have a single coordinator for network i/o so the systems connection and any given host isn't hammered. That said, the work we've already done on the WebKit2 Network Process assumes support for multiple Network Processes at some stage. Actually making use of them can be rolled in once the fundamentals in place. ~Brady Regards `Allan Sandfeld ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Multiprocess networking in WebKit
On Tuesday 04 December 2012, Adam Barth wrote: There's been a somewhat fragmented discussion across webkit-dev and various bugs about how we ought to approach multiprocess networking in WebKit. In an attempt to organize my thoughts, I wrote up a short design document that compares various approaches: https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD 4fQY/edit My hope is that this document will be useful as a starting point for discussion. If other folks have written similar documents, those might make valuable contributions to the discussion as well. I welcome your feedback, either via comments in the document or via this email thread. I like your ideas, but at least the two first points are in my mind operating system tasks, and already handled by some WebKit backends, so I hope it will be possible to put this logic at as high level as possible making it easier to ignore where it is unnecessary. I am considering it operating system tasks, because the benefits WebCore processes has in sharing connections or cache is the same all applications on a platform would have in doing the same. About the network process, I would just like to suggest not limiting it to one, not even to begin with. There is not much simplicity or efficiency to be gained by keeping all network request in the same process, and extra processes could be used for faster responses and increased security. Regards `Allan Sandfeld ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Multiprocess networking in WebKit
There's been a somewhat fragmented discussion across webkit-dev and various bugs about how we ought to approach multiprocess networking in WebKit. In an attempt to organize my thoughts, I wrote up a short design document that compares various approaches: https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD4fQY/edit My hope is that this document will be useful as a starting point for discussion. If other folks have written similar documents, those might make valuable contributions to the discussion as well. I welcome your feedback, either via comments in the document or via this email thread. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Multiprocess networking in WebKit
About MemCache considerations, you list these options... * Do not share storage * Share storage but hits in remote caches are asynchronous * Share storage and all cache hits are serviced synchronously Is there a fourth option? * Share storage and all cache hits are async in all cases (the resulting handle is returned asyncly, but the data is then directly addressable). And then maybe a fifth two-tiered option that builds on the above to get to something more satisfying? * Shared storage is accessible asyncly at the level of ResourceHandle (that fourth option). * Local handles to shared resources are accessible syncly at the level of todays MemCache, where the local memcache gets populated with handles to resources in shared storage. I'm merrily ignoring how decoded data is also associated with CacheResources (and how it can mutate depending on attributes of the Document for which it was most recently decoded). On Mon, Dec 3, 2012 at 4:16 PM, Adam Barth aba...@webkit.org wrote: There's been a somewhat fragmented discussion across webkit-dev and various bugs about how we ought to approach multiprocess networking in WebKit. In an attempt to organize my thoughts, I wrote up a short design document that compares various approaches: https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD4fQY/edit My hope is that this document will be useful as a starting point for discussion. If other folks have written similar documents, those might make valuable contributions to the discussion as well. I welcome your feedback, either via comments in the document or via this email thread. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Multiprocess networking in WebKit
On Dec 3, 2012, at 5:18 PM, Michael Nordman micha...@google.com wrote: About MemCache considerations, you list these options... * Do not share storage * Share storage but hits in remote caches are asynchronous * Share storage and all cache hits are serviced synchronously Is there a fourth option? * Share storage and all cache hits are async in all cases (the resulting handle is returned asyncly, but the data is then directly addressable). And then maybe a fifth two-tiered option that builds on the above to get to something more satisfying? * Shared storage is accessible asyncly at the level of ResourceHandle (that fourth option). * Local handles to shared resources are accessible syncly at the level of todays MemCache, where the local memcache gets populated with handles to resources in shared storage. I think this type of design point worth considering. It could work well with a read-only mapping of the shared resource data, reducing potential security risk from involving shared memory. Relatedly, you could imagine a design like: * Shared storage for raw resources is shared and accessible synchronously via a request-keyed index that's read-only to the web/render process but read-write in the network process. * Metadata and decoded data are unshared and use roughly the current cache data structures as used for the current WebCore memory cache. * Requests that miss the cache can still hit asynchronously based on a contents-indexed cache layer. (Sorry if that was a bit handwavey.) I'm merrily ignoring how decoded data is also associated with CacheResources (and how it can mutate depending on attributes of the Document for which it was most recently decoded). I guess my note above makes a proposal along those lines. On Mon, Dec 3, 2012 at 4:16 PM, Adam Barth aba...@webkit.org wrote: There's been a somewhat fragmented discussion across webkit-dev and various bugs about how we ought to approach multiprocess networking in WebKit. In an attempt to organize my thoughts, I wrote up a short design document that compares various approaches: https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD4fQY/edit My hope is that this document will be useful as a starting point for discussion. If other folks have written similar documents, those might make valuable contributions to the discussion as well. I welcome your feedback, either via comments in the document or via this email thread. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
