From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [IPv6:2a01:4f8:1c0c:6b10::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id CD1361F44D for ; Wed, 17 Apr 2024 23:16:17 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=muMYM4W0; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=FooxskYP; dkim-atps=neutral Received: from nue.mailmanlists.eu (localhost [127.0.0.1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 6647484374; Wed, 17 Apr 2024 23:16:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1713395769; bh=+jvJuI0lyOWyYvXML3/arlGAH+fuwFDBUmsGBaZcGgo=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=muMYM4W0pJm7FeBaJwY9WwPIbtnbwK/dZJTN3JKaF0s0Q5eUOsyXiD32rbC+2e/S4 BNNjfxz/y+UdjTWe9uhHQMyALkouLcXUBr2ITno+lgiFkOp/DWatzIEhgXJXGY74c3 QGVsBfUz4eXFyG9lu/G9s56PToworgRSE359hEOE= Received: from s.wrqvtbkv.outbound-mail.sendgrid.net (s.wrqvtbkv.outbound-mail.sendgrid.net [149.72.123.24]) by nue.mailmanlists.eu (Postfix) with ESMTPS id AB0A684326 for ; Wed, 17 Apr 2024 23:16:06 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=FooxskYP; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=tojcf4YF8/J5zzY8HdbQul1L7jrzat8/iaUJ5LC7Fs4=; b=FooxskYPjJmfjcnx8vgI5gZkPtnHQ2yV2Afo9TK9zcH0sfXPow7Op6vVLN6e0M/CuAAw pEqB3BTETAUOLkb5nf5zifje1QfQtnFurBGhNOydrvMl0ZaQW2sXdcUaEjUuV2E0w0oZyh MALpOSp9V4onW9qZVi7v2DYSi3Cyqakj9N63k/junTFJp2C98e1TocVENfSpQ5/Fg0MPN8 Rvbssos+VzHq+01FWbda+hB/op0+A059BxiaQDM9ZDUvdQ4n3gMaBXh/R53/pc7NmASMuY BF6xMxSvRIVpmA7eNiTC7OXzSrzKCUsNsCdGH8PaQ6HbzEnvSEwkMmmmHRFEevNQ== Received: by filterdrecv-854b845bd5-d477k with SMTP id filterdrecv-854b845bd5-d477k-1-66205835-7 2024-04-17 23:16:05.425480147 +0000 UTC m=+437197.223744523 Received: from herokuapp.com (unknown) by geopod-ismtpd-23 (SG) with ESMTP id AXVX3qOrR8SqFPCjnYVDcg for ; Wed, 17 Apr 2024 23:16:05.409 +0000 (UTC) Date: Wed, 17 Apr 2024 23:16:04 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 20215 X-Redmine-Issue-Author: ioquatix X-Redmine-Issue-Priority: Normal X-Redmine-Sender: akr X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-Redmine-MailingListIntegration-Message-Ids: 94176 X-SG-EID: =?us-ascii?Q?u001=2EjUYdomjR8qg=2FmRRJiw9jcD8=2F=2Fg2V+YCwM42AbEffAz+piO1ivD2ssVdIf?= =?us-ascii?Q?UsAvXwsSNeFNBeVO12+lrvx7XL=2FCynXeoHKbuwf?= =?us-ascii?Q?Y1cp7e8HqzgGFqE2KP=2FFfPZSO5FL+ARDUOVrg1t?= =?us-ascii?Q?WEwa7hKuQjDak2FT8Urs3pmrCAQ5UwQMGMmzLBN?= =?us-ascii?Q?sLgM4my4Abba5n9IQsocvIFrBG6tbtIbvBGKsOB?= =?us-ascii?Q?H9q6KCrrT92vDB6foJFcFgrhmZZRfDivpa5x3LR?= =?us-ascii?Q?6n71ooyR9BhG+df30fQZNwuyLw=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: WJGQ55ERLJ3LVUQI55R4C23MQLYXSZQJ X-Message-ID-Hash: WJGQ55ERLJ3LVUQI55R4C23MQLYXSZQJ X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.3 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:117580] [Ruby master Feature#20215] Introduce `IO#readable?` List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "akr (Akira Tanaka) via ruby-core" Cc: "akr (Akira Tanaka)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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/