FIFO hangs (Probably a bug of cygwin fifo)

[Takashi Yano]

On Fri, 16 May 2025 15:08:16 -0400
Ken Brown wrote:
> On 5/16/2025 4:59 AM, Takashi Yano via Cygwin wrote:
> > On Fri, 16 May 2025 08:46:40 +0900
> > Takashi Yano wrote:
> >> diff --git a/winsup/cygwin/local_includes/cygheap.h b/winsup/cygwin/local_includes/cygheap.h
> >> index fed87ec2b..7d11fbb37 100644
> >> --- a/winsup/cygwin/local_includes/cygheap.h
> >> +++ b/winsup/cygwin/local_includes/cygheap.h
> >> @@ -604,6 +604,8 @@ class cygheap_fdnew : public cygheap_fdmanip
> >>     {
> >>       if (cygheap->fdtab[fd])
> >>         cygheap->fdtab[fd]->inc_refcnt ();
> >> +    if (locked)
> >> +      cygheap->fdtab.unlock ();
> >>     }
> >>     void operator = (fhandler_base *fh) {cygheap->fdtab[fd] = fh;}
> >>   };
> > 
> > This should not be done, because the parent class cygheap_fdmanip
> > does that.
> Right.  But the other part of the patch (to syscalls.cc) looks right to 
> me, and I agree that it fixes the hang.  Here's my understanding of why 
> it works: The main thread tries to open the fifo for reading, but 
> fhandler_fifo::open blocks until it detects that someone is opening the 
> fifo for writing.  The other thread wants to do that, but it never gets 
> to the point of calling fhandler_fifo::open because it is stuck waiting 
> for the lock on cygheap->fdtab.  To fix this, we need to delay the 
> construction of the cygheap_fdnew object fd until after 
> fhandler_fifo::open has been called.
> 
> Do you agree with this explanation, or is there something else going on? 
>   In either case, I think it would be good to include at least a brief 
> explanation in your commit message, since this is a pretty subtle bug. 
> And thanks for finding the fix!

Thank you for confirming. I agree whth your explanation. I'd apply
the patch with above explanation.

Thanks!

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>