Hang in Deno.core.read

[bartlomieju]

Yep, the following test reproduces the issue: read() works once then hangs on the next. Run cargo test resource_test -- --nocapture against deno_core's testing crate after adding this test to reproduce.

test(async function testPipeLargeRead() {
  const [p1, p2] = op_pipe_create()
  const bufferSize = 65536
  const maxChunkSize = 1024
  const inBuffer = new Uint8Array(bufferSize)
  inBuffer[0] = 1
  assertEquals(maxChunkSize, await Deno.core.write(p1, inBuffer))
  const buf = new Uint8Array(1024)
  for (
    let chunkIndex = 0;
    chunkIndex <= bufferSize / maxChunkSize;
    chunkIndex++
  ) {
    console.log('trying read')
    assertEquals(maxChunkSize, await Deno.core.read(p2, buf))
    console.log('did read')
    // assertArrayEquals(buf.subarray(0), [i])
  }
})

You'll see this in the console:

...
trying read
did read
trying read

then the test doesn't even complete.

Originally posted by @aunyks in denoland/deno#22767 (comment)

[aunyks]

The program hangs on resource.read_byob(view).await which, in the above case, uses the PipeResource implementation where (thankfully) risk was acknowledged:

async {
    let mut lock = RcRef::map(self, |this| &this.rx).borrow_mut().await;
    // Note that we're holding a slice across an await point, so this code is very much not safe
    let res = lock.read(&mut buf).await?;
    Ok((res, buf))
  }
  .boxed_local()

It's worth checking whether this can be reproduced with other Resource implementers, but I'll leave that to someone who knows more about these internals than myself!