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

Reply via email to