public inbox for cygwin-developers@cygwin.com
 help / color / mirror / Atom feed
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>

  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).