From: Takashi Yano <takashi.yano@nifty.ne.jp>
To: cygwin-developers@cygwin.com
Subject: Re: cygwin 3.3.x: another problem that may be related to pipes
Date: Tue, 16 Nov 2021 00:11:37 +0900 [thread overview]
Message-ID: <20211116001137.7daf62c9f2815d5a92a56df0@nifty.ne.jp> (raw)
In-Reply-To: <20211115233601.f0c9717ee00908505534c976@nifty.ne.jp>
On Mon, 15 Nov 2021 23:36:01 +0900
Takashi Yano wrote:
> On Mon, 15 Nov 2021 08:57:43 -0500
> Ken Brown wrote:
> > 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?
>
> IIUC, WaitForMultipleObject() cannot wait for pipe object.
> Only the following objects are allowed to be waited.
>
> Change notification
> Console input
> Event
> Memory resource notification
> Mutex
> Process
> Semaphore
> Thread
> Waitable timer
>
> Note that the problem reported is not in raw_read(), but in raw_write().
>
> If you mean applying above patch for raw_write(), it proberbly fixes the
> issue as well.
>
> This is because ...
>
> If you pass the pipe handle to WFMO, it imediately returns WAIT_OBJECT_0,
> so your patch will work almost same with my patch.
I might be wrong. Your code certainly waits for something happening.
I am not sure why it works...
--
Takashi Yano <takashi.yano@nifty.ne.jp>
next prev parent reply other threads:[~2021-11-15 15:12 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
2021-11-15 14:36 ` Takashi Yano
2021-11-15 15:11 ` Takashi Yano [this message]
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=20211116001137.7daf62c9f2815d5a92a56df0@nifty.ne.jp \
--to=takashi.yano@nifty.ne.jp \
--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).