commit 7f5bc9be8069d0336c57e232abca4b63b3a881d1
author Chris Tam <godtamit@fuchsia.infra.roller.google.com> Wed Jun 29 17:03:41 2022 +0000
committer Copybara-Service <copybara-worker@google.com> Wed Jun 29 10:05:12 2022 -0700
tree bc7e05aebbf6c6239557d0bf3273fd05c7d0dad6
parent 25e1a21141e0dcdd92da7c53bba69651c42f1cc6

[roll] Roll fuchsia [stream] Use queueing for content size changes

This change breaks up serialization for content size changes and
implements a queueing scheme, similar to that of a reorder buffer from
Tomasulo's algorithm.

There are 4 primary operations that have some constraint on content
size, all with different behaviors:
  * Write
  * Append
  * Read
  * Set

Read operations are kept in the read queue. Reads are allowed to read up
to the minimum of the smallest outstanding truncate operation's size and
the current content size. Upon completion, reads are removed from the
queue -- no blocking is required.

Write operations are kept in the write queue. When initializing a write
operation, one of 2 scenarios will occur:
  1. If the write's content size requirement is less than the current
     content size and there are no set operations in front of it that
     sets the content size to less than the size requirement, it will
     allow the write proceed without blocking.
  2. Otherwise, the write will block until it is at the front of the
     write queue before allowing the write to proceed.

Append operations are kept in the write queue and upon initialization,
will block until the head of the write queue before proceeding with the
write if any of the following conditions are true:
  1. Other appends or writes that exceed the current content size exist
     in the queue.
  2. A set size operation exists in the queue.

Set size operations directly modify content size and can result in a
content size expansion or truncate, depending on where it is ordered and
the success, partial success, or failure of pending operations in front
of it. Additionally, set size operations may look to shrink a region
that pending read operations are reading from, so the set size must be
ordered after all the read operations complete. Thus, when enqueuing, a
set size operation will block until it is at the front of both the read
and write queues when any of the following conditions are true:
  1. A pending operation (write or append) writes beyond the current
     content size.
  2. A pending read operation reads beyond the target content size of
     the set operation.
  3. Another set size operation is in the queue.

Original-Fixed: 86278
Original-Fixed: 89713
Original-Fixed: 95975
Original-Bug: 82818
Original-Bug: 102657

Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/659788
Original-Revision: 5634c7b95d1c305e43de14c6d25d9175d5338477
GitOrigin-RevId: 9fd2f13cbf93558b7581f5cbee1dadfb6a9655fa
Change-Id: I35dbd5e8b8c7c1803c577c17da51c12d9a829a35