Re: 3.3.0: Possible regression in cygwin DLL (Win10); fixed in snapshot

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Nov  6 15:10, Takashi Yano wrote:
> # This topic is moved from cygwin@cygwin.com mailing list.
> 
> Hi Ken,
> 
> On Fri, 5 Nov 2021 16:08:31 -0400
> Ken Brown wrote:
> > On 11/5/2021 3:41 PM, Takashi Yano via Cygwin wrote:
> > > Thanks much for the detailed steps. I could reproduce the problem.
> > > 
> > > It seems that the cause is the overhaul for the pipe implementation.
> > > I also found the workaround for this issue. Please try:
> > > export CYGWIN=pipe_byte
> > > 
> > > Corinna, Ken,
> > > What about setting pipe mode to byte by default?
> > 
> > I have a vague recollection that this caused some other problem, but I'll have 
> > to review the email discussions from a few months ago.  I'm traveling at the 
> > moment and won't get to this for a few days.
> > 
> > In the meantime, could you explain (probably on cygwin-developers) why message 
> > mode causes the reported issue?  Also, does the problem occur only when there 
> > are non-Cygwin apps involved?
> 
> I digged deeper this problem and might find the cause.
> 
> Perhaps, C# program sometimes writes 0 byte to stdout.
> As a result, if stdout is a message pipe, raw_read() returns
> 0 byte and EOF is falsely detected. So, setting pipe type
> to byte solves the issue.

Given that EOF is reported as status STATUS_END_OF_FILE, wouldn't it
make sense to just check for 0 bytes in raw_read and continue the loop
as if literally nothing has happened?

> diff --git a/winsup/cygwin/fhandler_pipe.cc b/winsup/cygwin/fhandler_pipe.cc
> index 43771e8f7..bc06d157c 100644
> --- a/winsup/cygwin/fhandler_pipe.cc
> +++ b/winsup/cygwin/fhandler_pipe.cc
> @@ -393,7 +393,8 @@ fhandler_pipe::raw_read (void *ptr, size_t& len)
>  	    }
>  	}
>  
> -      if (nbytes_now == 0 || status == STATUS_BUFFER_OVERFLOW)
> +      if ((nbytes_now == 0 && !NT_SUCCESS (status))
> +	  || status == STATUS_BUFFER_OVERFLOW)
>  	break;
>      }
>    ReleaseMutex (read_mtx);

Oh, heh.

> I am not sure which is the better solution.

Me neither.  I remember that using a message type pipe fixed some
problem of old, but just because message pipes were a solution in the
past...  A quick search uncovered that the message type pipes have been
introduced in April 2012.  We might have to search the mailing list
archives to fiund the reason.

The question is if that problem is still present in the overhauled code
at all.

> P.S.
> Unfortunately, these solutions do not resolve the issue
> which is another issue with C# program:
> https://cygwin.com/pipermail/cygwin/2021-March/247987.html
> This still needs FILE_SYNCHRONOUS_IO_NONALERT flag.

If we want to add FILE_SYNCHRONOUS_IO_NONALERT, this would have to be
solved by running NtReadFile/NtWriteFile synchronously in a thread,
started on every invocation of raw_read/raw_write.  raw_read/raw_write
would then call cygwait on the thread object.  To break on signal or
thread cancallation events, it would have to call CancelSynchronousIo.
That's certainly doable.


Corinna