From: Ken Brown <kbrown@cornell.edu>
To: cygwin-developers@cygwin.com
Subject: Re: cygwin 3.3.x: another problem that may be related to pipes
Date: Mon, 15 Nov 2021 08:57:43 -0500 [thread overview]
Message-ID: <1f94e84c-59de-bf2c-f244-e4672b981987@cornell.edu> (raw)
In-Reply-To: <YZJaGJTxoDIpIq/g@calimero.vinschen.de>
On 11/15/2021 8:01 AM, Corinna Vinschen wrote:
> [Redirected to cygwin-developers]
>
> On Nov 15 17:18, Takashi Yano via Cygwin wrote:
>> raw_read()/raw_write() in fhandler_pipe.cc seems to need handling
>> of STATUS_PENDING in nonblocking mode.
>>
>> I also confirmed the following patch fixes the issue. However, I
>> am not very sure that this is the right thing.
>>
>> Corinna, Ken, what do you think?
>
> I'm puzzled. non-blocking pipes return STATUS_PENDING? What on earth
> is that supposed to mean on non-blocking (as opposed to asynchronous)
> pipes? The problem is that STATUS_PENDING theoretically requires
> to wait for... something, the pipe handle, perhaps, and then to check
> io.Status.
I noticed last week when I was debugging the XEmacs problem that NtReadFile
occasionally returned STATUS_PENDING. I commented on it here:
https://cygwin.com/pipermail/cygwin/2021-November/249827.html
But I promptly forgot about it when that turned out not to be the problem for
that bug. My thought at the time was that we needed something like this:
diff --git a/winsup/cygwin/fhandler_pipe.cc b/winsup/cygwin/fhandler_pipe.cc
index 9392a28c1..aaf09829d 100644
--- a/winsup/cygwin/fhandler_pipe.cc
+++ b/winsup/cygwin/fhandler_pipe.cc
@@ -336,9 +336,10 @@ fhandler_pipe::raw_read (void *ptr, size_t& len)
break;
status = NtReadFile (get_handle (), evt, NULL, NULL, &io, ptr,
len1, NULL, NULL);
- if (evt && status == STATUS_PENDING)
+ if (status == STATUS_PENDING)
{
- waitret = cygwait (evt, INFINITE, cw_cancel | cw_sig);
+ /* Very short-lived in the non-blocking case. */
+ waitret = cygwait (evt ?: get_handle (), INFINITE, cw_cancel | cw_sig);
/* If io.Status is STATUS_CANCELLED after CancelIo, IO has actually
been cancelled and io.Information contains the number of bytes
processed so far.
Takashi, does that fix the problem?
> Is it possible that nonblocking pipes need to be synchronous, i. e.,
> setting the FILE_SYNCHRONOUS_IO_NONALERT would fix that?
Ken
next prev parent reply other threads:[~2021-11-15 13:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <115203324.649908.1636923059546.ref@mail.yahoo.com>
[not found] ` <115203324.649908.1636923059546@mail.yahoo.com>
[not found] ` <20211115171811.844dce9cce2b4d13262d64f2@nifty.ne.jp>
2021-11-15 13:01 ` Corinna Vinschen
2021-11-15 13:57 ` Ken Brown [this message]
2021-11-15 14:36 ` Takashi Yano
2021-11-15 15:11 ` Takashi Yano
2021-11-15 15:27 ` Ken Brown
2021-11-15 15:36 ` Ken Brown
2021-11-15 16:45 ` Takashi Yano
2021-11-15 16:25 ` Corinna Vinschen
2021-11-15 14:50 ` Takashi Yano
2021-11-15 16:08 ` Corinna Vinschen
2021-11-15 16:37 ` Ken Brown
2021-11-15 16:52 ` Takashi Yano
2021-11-15 18:47 ` Ken Brown
2021-11-15 23:35 ` Takashi Yano
2021-11-15 23:49 ` Ken Brown
2021-11-16 3:28 ` Takashi Yano
2021-11-16 9:28 ` Corinna Vinschen
2021-11-16 9:45 ` Takashi Yano
2021-11-16 10:20 ` Takashi Yano
2021-11-16 14:35 ` Takashi Yano
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-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1f94e84c-59de-bf2c-f244-e4672b981987@cornell.edu \
--to=kbrown@cornell.edu \
--cc=cygwin-developers@cygwin.com \
/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).