Sv: Sv: open descriptor to named pipes sometimes fail

Wed Apr 8 18:49:31 GMT 2020

On 4/8/2020 8:53 AM, Ken Brown via Cygwin wrote:
> On 4/8/2020 4:52 AM, sten.kristian.ivarsson@gmail.com wrote:
>>> On 4/7/2020 2:38 PM, sten.kristian.ivarsson@gmail.com wrote:
>>>>> On 4/7/2020 11:10 AM, Kristian Ivarsson via Cygwin wrote:
>>>>>> Opening a (second) descriptor for (blocking) write sometimes fail
>>>>>>>>>>>> The provided test case sometimes succeed, but quite often fail with
>>>>>> ENOENT (in various indexes)
>>>>>>>>>>>> I haven't dug deeper to find the underlaying cause yet
>>>>>>>>>>>> Have anyone experienced this before ?
>>>>>>>>>> I can't reproduce this on my system.  I changed 1000 to 10000 and
>>>>> then ran your test case 10 times, and it never failed.  I tested both
>>>>> cygwin-3.1.4 and the HEAD of the topic/fifo branch (which I recently
>>>>> force-pushed in case you want to try it).
>>>>>>>>>> Can you run your test under strace and see if that provides a clue?
>>>>>>>> I'm running things on a few year old laptop, perhaps with less muscles
>>>> ;-)
>>>>>>>> With strace it was harder to reproduce, but I could reproduce it (and
>>>> it happen to be the first iteration this time)
>>>>>> Does this help?
>>>>>> --- a/winsup/cygwin/fhandler_fifo.cc
>>> +++ b/winsup/cygwin/fhandler_fifo.cc
>>> @@ -624,7 +624,8 @@ fhandler_fifo::open (int flags, mode_t)
>>>                     else
>>>                       goto success;
>>>                   }
>>> -             else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status))
>>> +             else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status)
>>> +                      | status == STATUS_OBJECT_NAME_NOT_FOUND)
>>>                   continue;
>>>                 else
>>>                   {
>>>> Did you mean to use the bit-or-operator or the or-operator ?
>> The or-operator.  Thanks for catching that.
>>> I did
>> ...
>>     else if (STATUS_PIPE_NO_INSTANCE_AVAILABLE (status) || status ==
>> STATUS_OBJECT_NAME_NOT_FOUND)
>> ...
>> and with that change I cannot reproduce the error in the test-program
>> Great.  I'll push it to the topic/fifo branch.  For the record, that patch was 
> motivated by your strace output, which showed NtOpenFile failing with status 
> 0xC0000034, which is STATUS_OBJECT_NAME_NOT_FOUND.

This was not a well-thought-out change. It creates a drastic slow-down. I'll 
have to find a better solution.
Ken