*
 * This nesting is typical but not strict. For example, when calls use "Expect: continue" the
 * request body start and end events occur within the response header events. Similarly,
 * [duplex calls][RequestBody.isDuplex] interleave the request and response bodies.
 *
 * Since connections may be reused, the proxy selection, DNS, and connect events may not be present
 * for a call. In future releases of OkHttp these events may also occur concurrently to permit

      if (result == CancellationException.class) {
        assertTrue(future.isCancelled());
        assertTrue(cancellationSuccess.get());
        // cancellation can interleave in 3 ways
        // 1. prior to setFuture
        // 2. after setFuture before set() on the future assigned
        // 3. after setFuture and set() are called but before the listener completes.

      if (result == CancellationException.class) {
        assertTrue(future.isCancelled());
        assertTrue(cancellationSuccess.get());
        // cancellation can interleave in 3 ways
        // 1. prior to setFuture
        // 2. after setFuture before set() on the future assigned
        // 3. after setFuture and set() are called but before the listener completes.

   *
   * ### Duplex Transmission
   *
   * With regular HTTP calls the request always completes sending before the response may begin
   * receiving. With duplex the request and response may be interleaved! That is, request body bytes
   * may be sent after response headers or body bytes have been received.
   *
   * Though any call may be initiated as a duplex call, only web servers that are specially

   *  * If it is a message frame this will result in a single call to [FrameCallback.onReadMessage].
   *    If the message spans multiple frames, each interleaved control frame will result in a
   *    corresponding call to [FrameCallback].
   */
  @Throws(IOException::class)
  fun processNextFrame() {
    check(!closed) { "closed" }

    readHeader()

    <glob pattern="*.wmx"/>
  </mime-type>
  <mime-type type="video/x-ms-wvx">
    <glob pattern="*.wvx"/>
  </mime-type>

  <mime-type type="video/x-msvideo">
    <_comment>Audio Video Interleave File</_comment>
    <alias type="video/avi"/>
    <alias type="video/msvideo"/>
    <magic priority="50">
      <match value="RIFF....AVI " type="string" offset="0"
             mask="0xFFFFFFFF00000000FFFFFFFF"/>

   * We always do timeouts in the HTTP server role. For clients, we only do timeouts after the
   * request is transmitted. This is only interesting for duplex calls where the request and
   * response may be interleaved.
   *
   * Read this value only once for each enter/exit pair because its value can change.
   */
  private fun doReadTimeout() = !connection.client || sink.closed || sink.finished

  /**

  /**
   * Each instance of MinMaxPriorityQueue encapsulates two instances of Heap: a min-heap and a
   * max-heap. Conceptually, these might each have their own array for storage, but for efficiency's
   * sake they are stored interleaved on alternate heap levels in the same array (MMPQ.queue).
   */
  @WeakOuter
  private final class Heap {
    final Ordering<E> ordering;

    @SuppressWarnings("nullness:initialization.field.uninitialized")

				"video/vnd.iptvforum.ttsmpeg2",
				"video/vnd.motorola.video",
				"video/vnd.motorola.videop",
				"video/vnd.mpegurl",
				"video/vnd.ms-playready.media.pyv",
				"video/vnd.nokia.interleaved-multimedia",
				"video/vnd.nokia.videovoip",
				"video/vnd.objectvideo",
				"video/vnd.sealed.mpeg1",
				"video/vnd.sealed.mpeg4",
				"video/vnd.sealed.swf",
				"video/vnd.sealedmedia.softseal.mov",