MemoryBlockCache won't allow initializing, or growing an existing buffer,
above the limit (min of 'media.memory_caches_combined_limit_kb' or
sysmem*'media.memory_caches_combined_limit_pc_sysmem'/100).
MozReview-Commit-ID: 6MkwFp2eeth
--HG--
extra : rebase_source : 17345f6fe9f00fddfbef87090665afccaabb2cf5
This will be useful to let the MediaCache flush its block cache without having
to restart from scratch (and risk failing).
MozReview-Commit-ID: At3mxH9jb9m
--HG--
extra : rebase_source : b5ac513c6d6d100c8eb41220991388470c0b1a5e
The only external use of Close was always followed by an implicit destruction
(by resetting the RefPtr), so we don't need to expose it, and it can be done
from the destructor.
FileBlockCache keeps its Close() function for internal use.
Also, FileBlockCache::mIsOpen is redundant, as it's true iff mThread is not
null.
MozReview-Commit-ID: LV7YVrwJvGG
--HG--
extra : rebase_source : 23decadf249b9e63190b3e19d81edc4a090afcef
No errors are expected to happen in MemoryBlockCache (except a few
'InitAllocation', which would still be good to know about), but instead of
taking drastic measures in these cases (i.e., crash), I would prefer to
collect some telemetry first.
MozReview-Commit-ID: 4WdFS34lgzj
--HG--
extra : rebase_source : 5600d0b93d4d438d8cc9cf5a74d9fbf24fe2822e
Memory-backed block cache.
At initialization, allocates memory needed to store the expected content
length.
If MediaCache attempts to write/move beyond the expected size, we grow the
buffer accordingly, as we cannot fully trust HTTP headers. (Future patch will
ensure we put a limit to this growth.)
MozReview-Commit-ID: GHxYMGXYrwI
--HG--
rename : dom/media/MediaBlockCacheBase.h => dom/media/MemoryBlockCache.h
extra : rebase_source : 4fe263006839ba82a77d124f147adf5943cfa651
Jean-Yves Avenard
Gerald Squelart