This document descibes the browser-process implementation of the Cache Storage specification.
Where ‘=>’ represents ownership, ‘->’ is a reference, and ‘~>’ is a weak reference.
CacheStorageManagercan own multiple
CacheStoragecan own multiple
StoragePartitionImpleffectively owns the
CacheStorageContextImplin the sense that it calls
CacheStorageContextImpl::Shutdown()on deletion which resets its
CacheStorageDispatcherHostholds onto handles for:
CacheStorageCacheDataHandleis the blob data handle for a response body and it holds a
CacheStorageCacheHandle. It streams from the
disk_cache::Entryresponse stream. It's necessary that the
CacheStorageCache) stays open so long as one of its
disk_cache::Entrys is reachable. Otherwise, a new backend might open and clobber the entry.
CacheStorageCacheHandleto keep the cache alive since the operation is asynchronous.
CacheStoragefor a given origin, loading
CacheStorages on demand.
MemoryCache) on initialization.
CacheStorageand deleted either when
CacheStoragedeletes or when the last
CacheStorageCacheHandlefor the cache is gone.
CacheStorageCacheis deleted, so to is the
CacheStorageCachemay be deleted before the
CacheStoragedestruction), so it must be checked for validity before use.
origin is a hash of the origin and
cache is a GUID generated at the cache's creation time.
The reason a random directory is used for a cache is so that a cache can be doomed and still used by old references while another cache with the same name is created.
CacheStorage creates its own index file (index.txt), which contains a mapping of cache names to its path on disk. On
CacheStorage initialization, directories not in the index are deleted.
CacheStorageCache has a
disk_cache::Backend backend, which writes in the
A cache is represented by a
disk_cache::Backend. The Request/Response pairs referred to in the specification are stored as
The entries are keyed by full URL. This has a few ramifications:
ignoreSearch) must scan every entry in the cache.
The above could be fixed by changes to the backend or by introducing indirect entries in the cache. The indirect entries would be for the query-stripped request URL. It would point to entries to each query request/response pair and for each vary request/response pair.
CacheStorageContextImplwhich is created on UI but otherwise runs and is deleted on IO.
CacheStorageDispatcherHostwhich is created on UI but otherwise runs and is deleted on IO.
disk_cache::Backendlives on the IO thread and uses its own worker pool to implement async operations.
CacheStorage) is still alive. Once the object is deleted, the callbacks are dropped. We don't worry about dropped callbacks on shutdown. If deleting prior to shutdown, one should
CacheStorageCacheto ensure that all operations have completed before deleting it.
Operations are scheduled in a sequential scheduler (
CacheStorageCache has its own scheduler. If an operation freezes, then the scheduler is frozen. If a
CacheStorage call winds up calling something from every
CacheStorage::Match), then one frozen
CacheStorageCache can freeze the
CacheStorage as well. This has happened in the past (
QuotaManager to determine how much room was available, which in turn called
Cache::Size). Be careful to avoid situations in which one operation triggers a dependency on another operation from the same scheduler.
At the end of an operation, the scheduler needs to be kicked to start the next operation. The idiom for this in CacheStorage/ is to wrap the operation's callback with a function that will run the callback as well as advance the scheduler. So long as the operation runs its wrapped callback the scheduler will advance.