Because it's a circular buffer, fragments are "garbage collected" by the write
cursor wrapping around and overwriting them.
The difficulty in making fragments for a single object contiguous is the data
arrives non-contiguously. The memory cost of buffering the data would be very
large along with
It seems pretty unlikely that __gcov_flush() is async signal safe so we can't
safely call it from a signal handler. #1937 is trying to fix the shutdown
sequence so this kind of thing can be done safely.
> On May 30, 2017, at 2:32 PM, shinr...@apache.org wrote:
>
> This is an automated email fr
Thanks Alan.
Does a fragment store only one object?
I understand:
> The difficulty in making fragments for a single object contiguous is the
data arrives non-contiguously.
Our objects are split and stored into may-be-not-contiguous fragments. Do
you think it's a good idea to tweak the GC to re-
Each fragment is part of a specific object. No two objects share a fragment.
I don't think making the fragments contiguous will be of much benefit. Either
the system is not busy, in which case the additional seek time doesn't matter,
or it's busy in which case many other objects are being read an
Hi all,
We've created a wiki page for QUIC project.
https://cwiki.apache.org/confluence/display/TS/QUIC
Please refer to the page if you are interested in implementing QUIC. All
materials, tools, rules, etc will be linked from the page.
Thanks,
Masakazu
Hi Team,
For a cache-miss content (let's say 100MB), if the first client is in slow
speed network, let's say 100kbps, then the cache fill will be limited to be
100kbps as well, this will restrict the subsequence clients's downloading
rate if *read_while_writer is enabled*. I think, correct me if I
