From: "akr (Akira Tanaka) via ruby-core" <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: "akr (Akira Tanaka)" <noreply@ruby-lang.org>
Subject: [ruby-core:117580] [Ruby master Feature#20215] Introduce `IO#readable?`
Date: Wed, 17 Apr 2024 23:16:04 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-107980.20240417231605.3344@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-20215.20240126051916.3344@ruby-lang.org
Issue #20215 has been updated by akr (Akira Tanaka).
Thank you for the explanation of the motivation.
I feel it is reasonable.
However, mame-san still had a question yesterday: why don't you detect an error in writing a request?
I guess it is because writing the request may not fail.
It needs two writes to detect the error.
(The first write in a client application causes the client kernel to send a packet to the server.
The server kernel responds to it with a RST packet because the server socket is closed.
The client kernel receives the RST packet and detects we cannot send data in the connection.
The second write in the client application will cause an error.)
Please point out if I am wrong.
My next question is why `io.eof?` and `io.wait_readable(0)` doesn't fulfill your motivation.
My current guess is related to the buffering mechanism of IO class.
But I'm not certain.
----------------------------------------
Feature #20215: Introduce `IO#readable?`
https://bugs.ruby-lang.org/issues/20215#change-107980
* Author: ioquatix (Samuel Williams)
* Status: Open
----------------------------------------
There are some cases where, as an optimisation, it's useful to know whether more data is potentially available.
We already have `IO#eof?` but the problem with using `IO#eof?` is that it can block indefinitely for sockets.
Therefore, code which uses `IO#eof?` to determine if there is potentially more data, may hang.
```ruby
def make_request(path = "/")
client = connect_remote_host
# HTTP/1.0 request:
client.write("GET #{path} HTTP/1.0\r\n\r\n")
# Read response
client.gets("\r\n") # => "HTTP/1.0 200 OK\r\n"
# Assuming connection close, there are two things the server can do:
# 1. peer.close
# 2. peer.write(...); peer.close
if client.eof? # <--- Can hang here!
puts "Connection closed"
# Avoid yielding as we know there definitely won't be any data.
else
puts "Connection open, data may be available..."
# There might be data available, so yield.
yield(client)
end
ensure
client&.close
end
make_request do |client|
puts client.read # <--- Prefer to wait here.
end
```
The proposed `IO#readable?` is similar to `IO#eof?` but rather than blocking, would simply return false. The expectation is the user will subsequently call `read` which may then wait.
The proposed implementation would look something like this:
```ruby
class IO
def readable?
!self.closed?
end
end
class BasicSocket
# Is it likely that the socket is still connected?
# May return false positive, but won't return false negative.
def readable?
return false unless super
# If we can wait for the socket to become readable, we know that the socket may still be open.
result = self.recv_nonblock(1, MSG_PEEK, exception: false)
# No data was available - newer Ruby can return nil instead of empty string:
return false if result.nil?
# Either there was some data available, or we can wait to see if there is data avaialble.
return !result.empty? || result == :wait_readable
rescue Errno::ECONNRESET
# This might be thrown by recv_nonblock.
return false
end
end
```
For `IO` itself, when there is buffered data, `readable?` would also return true immediately, similar to `eof?`. This is not shown in the above implementation as I'm not sure if there is any Ruby method which exposes "there is buffered data".
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- ruby-core@ml.ruby-lang.org
To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/
next prev parent reply other threads:[~2024-04-17 23:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-26 5:19 [ruby-core:116456] [Ruby master Feature#20215] Introduce `IO#readable?` ioquatix (Samuel Williams) via ruby-core
2024-02-01 6:19 ` [ruby-core:116546] " shyouhei (Shyouhei Urabe) via ruby-core
2024-02-01 14:59 ` [ruby-core:116547] " Dan0042 (Daniel DeLorme) via ruby-core
2024-02-02 21:06 ` [ruby-core:116561] " Eregon (Benoit Daloze) via ruby-core
2024-02-03 17:13 ` [ruby-core:116566] " Dan0042 (Daniel DeLorme) via ruby-core
2024-02-03 19:53 ` [ruby-core:116567] " Dan0042 (Daniel DeLorme) via ruby-core
2024-02-19 18:44 ` [ruby-core:116851] " forthoney (Seong-Heon Jung) via ruby-core
2024-04-16 1:13 ` [ruby-core:117521] " ioquatix (Samuel Williams) via ruby-core
2024-04-16 9:54 ` [ruby-core:117528] " ioquatix (Samuel Williams) via ruby-core
2024-04-16 17:36 ` [ruby-core:117537] " mame (Yusuke Endoh) via ruby-core
2024-04-17 0:07 ` [ruby-core:117541] " ioquatix (Samuel Williams) via ruby-core
2024-04-17 1:13 ` [ruby-core:117542] " akr (Akira Tanaka) via ruby-core
2024-04-17 4:25 ` [ruby-core:117544] " ioquatix (Samuel Williams) via ruby-core
2024-04-17 23:16 ` akr (Akira Tanaka) via ruby-core [this message]
2024-04-19 1:20 ` [ruby-core:117603] " Dan0042 (Daniel DeLorme) via ruby-core
2024-04-22 4:06 ` [ruby-core:117636] " ioquatix (Samuel Williams) via ruby-core
2024-04-22 4:08 ` [ruby-core:117637] " ioquatix (Samuel Williams) via ruby-core
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-107980.20240417231605.3344@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
--cc=noreply@ruby-lang.org \
--cc=ruby-core@ml.ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).