MediaCacheStreams have owning shared pointers to their MediaCache, and
a MediaCache owns itself while an update is in flight.
A non-owning pointer `gMediaCache` is only used by GetMediaCache and
~MediaCache to manage the one file-backed MediaCache.
MozReview-Commit-ID: AQHuXWGrKt6
--HG--
extra : rebase_source : f256e20080b8701f87418209aa42c5a0fe3f5239
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
Don't go over the lowest of 'media.memory_caches_combined_limit_kb'
(kilobytes) or 'media.memory_caches_combined_limit_pc_sysmem' (percents of
system memory).
Added more logging around creation/destruction of MediaCaches.
MozReview-Commit-ID: Cdz4ycyn1RR
--HG--
extra : rebase_source : 63168234f186c3ef9c0289a189a647d67d8526a4
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
Because blocks may not necessarily be held in files anymore.
MozReview-Commit-ID: 2GNc7B5w2Jt
--HG--
extra : rebase_source : 4ceda80ca6736b159d8b726cdcfb8d7f74cf8529
This is necessary before we can make FileBlockCache depend on another
ref-counted base in the following patch.
MozReview-Commit-ID: 8bfNwQhY8k0
--HG--
extra : rebase_source : b216d0af3e4b5abb68532f2547597c4f04585a71
The initial telemetry collection was done in NotifyDataLength() because that
was the first point where the length was introduced; but some extra code was
needed to ensure that were collecting the first length.
Now that this initial length is passed directly to Init(), we can report that
number instead.
In the "worst" case, it will actually be a bit more correct about what we
initially wanted to report, i.e., the initial length given by the HTTP
response header; and it's what we really want to know, now that we are using
this number to make a decision about which MediaCache to use.
MozReview-Commit-ID: 11Th8pensZt
--HG--
extra : rebase_source : 97a6d2dcbfad6c9b37819bfe6471baff2ec7e335
This will give enough information (for now) for GetMediaCache to decide whether
to use the (one global shared) file-backed MediaCache, or a discrete memory-
backed MediaCache.
(Note that GetMediaCache doesn't use this length yet in this patch.)
MozReview-Commit-ID: 5B2E3sIsc4k
--HG--
extra : rebase_source : 940e782665bf2c3640bbe7389fca02ea7c1482cd
This is the new recommended way to create&initialize the file-backed
MediaCache.
In future patches, this will also allow the creation of memory-backed
MediaCache objects.
MozReview-Commit-ID: 6RUlNW2eBPP
--HG--
extra : rebase_source : 0b3e6fae71207076812b5cb9172d4497d3e68ea2
MediaCacheFlusher constructs itself when needed by the first MediaCache, and
destroys itself when the last MediaCache unregisters itself.
Some MediaCache member functions had to be made non-static, so they could be
called for each instance.
MozReview-Commit-ID: 5Dh9mEKbZHg
--HG--
extra : rebase_source : 1570e30787ba486f9436b4b05aa3cfa0329d1ee7