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