[PATCH 00/21] FIFO: Support multiple readers

[Ken Brown]

On 5/19/2020 10:07 AM, Takashi Yano wrote:
> On Tue, 19 May 2020 09:37:17 -0400
> Ken Brown via Cygwin-patches <cygwin-patches@cygwin.com> wrote:
>> On 5/19/2020 8:51 AM, Ken Brown via Cygwin-patches wrote:
>>> On 5/19/2020 2:15 AM, Takashi Yano via Cygwin-patches wrote:
>>>> On Tue, 19 May 2020 10:26:09 +0900
>>>> Takashi Yano via Cygwin-patches <cygwin-patches@cygwin.com> wrote:
>>>>> Hi Ken,
>>>>>
>>>>> On Mon, 18 May 2020 13:42:19 -0400
>>>>> Ken Brown via Cygwin-patches <cygwin-patches@cygwin.com> wrote:
>>>>>> Hi Takashi,
>>>>>>
>>>>>> On 5/18/2020 12:03 PM, Ken Brown via Cygwin-patches wrote:
>>>>>>> On 5/18/2020 1:36 AM, Takashi Yano via Cygwin-patches wrote:
>>>>>>>> On Mon, 18 May 2020 14:25:19 +0900
>>>>>>>> Takashi Yano via Cygwin-patches <cygwin-patches@cygwin.com> wrote:
>>>>>>>>> However, mc hangs by several operations.
>>>>>>>>>
>>>>>>>>> To reproduce this:
>>>>>>>>> 1. Start mc with 'env SHELL=tcsh mc -a'
>>>>>>>>
>>>>>>>> I mean 'env SHELL=/bin/tcsh mc -a'
>>>>>>>>
>>>>>>>>> 2. Select a file using up/down cursor keys.
>>>>>>>>> 3. Press F3 (View) key.
>>>>>>>
>>>>>>> Thanks for the report.  I can reproduce the problem and will look into it.
>>>>>>
>>>>>> I'm not convinced that this is a FIFO bug.  I tried two things.
>>>>>>
>>>>>> 1. I attached gdb to mc while it was hanging and got the following backtrace
>>>>>> (abbreviated):
>>>>>>
>>>>>> #1  0x00007ff901638037 in WaitForMultipleObjectsEx ()
>>>>>> #2  0x00007ff901637f1e in WaitForMultipleObjects ()
>>>>>> #3  0x0000000180048df5 in cygwait () at ...winsup/cygwin/cygwait.cc:75
>>>>>> #4  0x000000018019b1c0 in wait4 () at ...winsup/cygwin/wait.cc:80
>>>>>> #5  0x000000018019afea in waitpid () at ...winsup/cygwin/wait.cc:28
>>>>>> #6  0x000000018017d2d8 in pclose () at ...winsup/cygwin/syscalls.cc:4627
>>>>>> #7  0x000000018015943b in _sigfe () at sigfe.s:35
>>>>>> #8  0x000000010040d002 in get_popen_information () at filemanager/ext.c:561
>>>>>> [...]
>>>>>>
>>>>>> So pclose is blocking after calling waitpid.  As far as I can tell from looking
>>>>>> at backtraces of all threads, there are no FIFOs open.
>>>>>>
>>>>>> 2. I ran mc under strace (after exporting SHELL=/bin/tcsh), and I didn't see
>>>>>> anything suspicious involving FIFOs.  But I saw many EBADF errors from fstat
>>>>>> and
>>>>>> close that don't appear to be related to FIFOs.
>>>>>>
>>>>>> So my best guess at this point is that the FIFO changes just exposed some
>>>>>> unrelated bug(s).
>>>>>>
>>>>>> Prior to the FIFO changes, mc would get an error when it tried to open
>>>>>> tcsh_fifo
>>>>>> the second time, and it would then set
>>>>>>
>>>>>>      mc_global.tty.use_subshell = FALSE;
>>>>>>
>>>>>> see the mc source file subshell/common.c:1087.
>>>>>
>>>>> I looked into this problem and found pclose() stucks if FIFO
>>>>> is opened.
>>>>>
>>>>> Attached is a simple test case. It works under cygwin 3.1.4,
>>>>> but stucks at pclose() under cygwin git head.
>>>>>
>>>>> Isn't this a FIFO related issue?
>>>>
>>>> In the test case, fhandler_fifo::close() called from /bin/true
>>>> seems to get into infinite loop at:
>>>>
>>>> do
>>>> ...
>>>> while (inc_nreaders () > 0 && !found);
>>>
>>> Thank you!  I see the problem.  After the popen call, the original
>>> fhandler_fifo's fifo_reader_thread was no longer running, so it was unable to
>>> take ownership.
>>>
>>> It might take a little while for me to figure out how to fix this.
>>
>> Actually, I think it's easy.  Please try the two attached patches.  The second
>> one is the crucial one for the mc problem, but the first is something I noticed
>> while working on this.
>>
>> I just did a quick and dirty patch for testing purposes.  I still have to do a
>> lot of cleanup and make sure the fix doesn't break something else.
> 
> For a shor time, I tested these patches, and confirmed
> that this fixes the problem.
> 
> Thanks for the quick response.

I've just pushed cleaned-up versions of the patches.

Ken