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!

[tristan-f-r]

it seems that the error is propagated by impl_readable_byob

[0f-0b]

I think this behavior is correct. op_pipe_create creates a pipe with a capacity of 1024 bytes, which results in only the first 1024 bytes of inBuffer being written into the pipe. In the first iteration of the read loop, all 1024 bytes are read out of the pipe, so in the second iteration, there is no more data available, and read hangs forever.