IO.select misses readability when the same UNIXSocket is also in the write list #9505

Environment

jruby 10.1.0.0 (4.0.0) 2026-04-20 32f988b78c OpenJDK 64-Bit Server VM 21.0.11 on 21.0.11 +indy +jit [arm64-darwin]

Compared with:

ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [arm64-darwin24]

Reproduction

# frozen_string_literal: true

require "socket"

local, remote = UNIXSocket.pair

begin
  remote.write("Hello")

  readable, writable, priority = IO.select([local], [local], nil, 0)

  puts RUBY_DESCRIPTION
  puts "readable: #{readable.include?(local)}"
  puts "writable: #{writable.include?(local)}"
  puts "priority: #{priority.include?(local)}"

  unless readable.include?(local) && writable.include?(local)
    warn "Expected socket to be both readable and writable."
    exit 1
  end
ensure
  local.close
  remote.close
end

Expected behavior

When the same socket is present in both the read and write arrays, and it is both readable and writable, IO.select should report it in both result arrays.

CRuby reports:

ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [arm64-darwin24]
readable: true
writable: true
priority: false

Actual behavior

JRuby only reports writability and omits readability:

jruby 10.1.0.0 (4.0.0) 2026-04-20 32f988b78c OpenJDK 64-Bit Server VM 21.0.11 on 21.0.11 +indy +jit [arm64-darwin]
readable: false
writable: true
priority: false
Expected socket to be both readable and writable.

Context

This came up while testing io-event's IO::Event::Selector::Select implementation on JRuby. The selector may have separate fibers waiting for readability and writability on the same socket. On CRuby both waiters are dispatched in one IO.select call; on JRuby the readable waiter is missed unless we perform separate follow-up IO.select calls for read and write interest.