Feature #18411: Introduce `Fiber.blocking` for disabling scheduler.

• Status: Closed
• Assignee: ioquatix (Samuel Williams)
• Target version: -

[ioquatix (Samuel Williams)]

When implementing pure-ruby IO scheduler, we may need to invoke some Ruby IO operations without entering the scheduler.

def io_write(fiber, io, buffer, length)
  offset = 0
  
  while length > 0
    # From offset until the end:
    chunk = buffer.to_str(offset, length)
    case result = io.write_nonblock(chunk, exception: false)
    when :wait_readable
      self.io_wait(fiber, io, IO::READABLE)
    when :wait_writable
      self.io_wait(fiber, io, IO::WRITABLE)
    else
      offset += result
      length -= result
    end
  end
  
  return offset
end

There are some cases where even in this code read_nonblock can invoke fiber scheduler creating infinite recursion.

Therefore, I propose to introduce Fiber.blocking{...} which has almost identical implementation to Fiber.new(blocking: true) {}.resume.

In the above code, we change the line:

    case result = io.write_nonblock(chunk, exception: false)

to

    case result = Fiber.blocking{io.write_nonblock(chunk, exception: false)}

This ensures that write_nonblock can never enter the scheduler again.

[ioquatix (Samuel Williams)]

@matz (Yukihiro Matsumoto) this isn't strictly necessary but makes pure Ruby implementation of IO read/write hooks more efficient. I'm not sure if there is valid case for general user code. Can we consider it for Ruby 3.1?

[ioquatix (Samuel Williams)]

• Description updated (diff)

[jeremyevans0 (Jeremy Evans)]

• Tracker changed from Bug to Feature
• Backport deleted (2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN)

[ko1 (Koichi Sasada)]

Let me confirm that why write_nonblock calls a fiber scheduler?
Or does it solve if write_nonblock doesn't call a fiber scheduler?

[ioquatix (Samuel Williams)]

io_uring handles non-blocking read and write system calls using the ring buffer. So even read_nonblock and write_nonblock system calls can go via the fiber scheduler. The system call itself is asynchronous even if the IO is non-blocking. I have not investigated the performance much since io_uring has not been in a completely usable state yet. But recently it was much better, so I may begin this evaluation soon.

[ioquatix (Samuel Williams)]

It was accepted.

PR: https://github.com/ruby/ruby/pull/6498

[ioquatix (Samuel Williams)]

• Status changed from Open to Closed
• Assignee set to ioquatix (Samuel Williams)

It was merged.