[Compatibility] Adding IO#timeout

[itarato]

Source: #3039

Introduce IO#timeout= and IO#timeout which can cause
IO::TimeoutError to be raised if a blocking operation exceeds the
specified timeout. [Feature #18630]

STDIN.timeout = 1
STDIN.read # => Blocking operation timed out! (IO::TimeoutError)

Caveat

This PR does not contain updating the error type for TCPSocket #open and #new. It seems we don't have the whole timeout logic implemented for that yet. I rather have them implemented in a separate PR to keep it clean.

[eregon]

This looks fine. My main concern is we shouldn't make the no-timeout-set case slower, but that seems already fine here.

I wonder if it should only affect read/write though, or other operations as well?

Also could you untag the CRuby tests for this: test/ruby/test_io_timeout.rb?

[eregon]

Does io.timeout = nil sets nonblock to false?
Could you add specs for the interaction of timeout and nonblock?

[itarato]

Sure thing

[andrykonchin]

Nice, it's a proper place for this helper method 👍.

[andrykonchin]

major: Looks like error handling isn't accurate. Wondering if it's easy to test these cases.

It seems Truffle::IOOperations.poll:

• returns false when it times out
• calls Errno.handle_errno(errno) and consequently raises SystemCallError exception if there is error other than EINTR
• returns nonnegative Integer otherwise

[itarato]

As chatted about this - I'm attempting to update

truffleruby/src/main/ruby/truffleruby/core/truffle/io_operations.rb

Line 248 in 7e07d2b

false # timeout

from returning false to 0. The reason is - Posix's poll does return 0 on timeout (not exactly like this, when timeout happens on an EINTR, but the idea is pretty much equal). As well there is a lot of code doing poll(_) > 0 - which would raise with a boolean result.

And regarding:

calls Errno.handle_errno(errno) and consequently raises SystemCallError exception if there is error other than EINTR

Raising inside poll is fine, as far as I can tell we want that anyways. I would keep the check for -1 in read/write too, just to be safe and pragmatic.

[eregon]

Looks great, thank you!
Only a few remaining polishing touches needed.

[eregon]

Thank you for all the work on this PR, it's a non-trivial piece of functionality to integrate, it looks great.

[eregon]

@itarato FWIW @andrykonchin tried integrating this PR but there have been various issues and corner cases causing issues/hangs/etc in CI, so we eventually moved to some more pressing things.

[itarato]

Thanks for the ping @eregon, since it was open for a year I figured it's gotta be obsolete.