|
From: | Jim Porter |
Subject: | bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin |
Date: | Fri, 24 Jun 2022 16:03:13 -0700 |
On 6/24/2022 3:23 PM, Sean Whitton wrote:
On Fri 24 Jun 2022 at 09:53AM -07, Jim Porter wrote:How about the attached patch? I didn't check for specific platforms to enable the "third EOF" behavior, since a) it's hard to say for sure which platforms might have this issue (especially since Cygwin will be fixing it), and b) this lets us avoid worrying about Tramp compatibility.Avoiding the TRAMP issues makes sense, but could you explain why you don't think there could be an issue with sending a process too many EOFs? It's not immediately obvious to me.
Eshell was already sending too many EOFs in some cases, and we haven't seen any issues with it (that I know of). For example, consider the command:
*echo hi | revIn this case, we send the string "hi\n" over the pipe, followed by 2 EOFs (one from the stdout handle and one from the stderr handle). The POSIX standard says[1] (thanks to Eliot Moss on the Cygwin mailing list for citing this passage):
When [EOF is] received, all the bytes waiting to be read are immediately passed to the process without waiting for a <newline>, and the EOF is discarded. Thus, if there are no bytes waiting (that is, the EOF occurred at the beginning of a line), a byte count of zero shall be returned from the read(), representing an end-of-file indication.I interpret that to mean that the preferred way to indicate end-of-file to `rev' in this case is to send it "hi [NL] [EOF]". The second EOF that Eshell sends when closing the stderr output handle is superfluous, but it works fine as far as I can tell.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html
[Prev in Thread] | Current Thread | [Next in Thread] |