Re: open write descriptor on named pipe sometime results in ENOENT

[Ken Brown <kbrown@cornell.edu>]

On 4/18/2020 5:48 PM, Ken Brown via Cygwin wrote:
> On 4/18/2020 11:24 AM, sten.kristian.ivarsson@gmail.com wrote:
>> Hey all
>>
>>
>> We're trying to nail down some issues with using named pipes
>>
>> The issue we're getting is deterministic (ENXIO) but it is not this one, but
>> we think this issue is worth reporting anyway
>>
>>
>> We're using the branch topic/fifo
>>
>>
>>
>> The program explained in short is:
>>
>>
>> - One main (parent) pipe that lives through the whole execution
>>
>> - The main process forks 'children' child-processes that creates their own
>> (unique) named pipes
>>
>> - Each child forks 'children' grans-child-processes that just writes some
>> bogus messages back to the unique child pipe
>>
>> - Each child writes a bogus message back to the main process
>>
>> - Every process creates a write and a read descriptor, but the write
>> descriptor is just a dummy descriptor (to somehow keep the pipe alive
>> without being bombarded with signals)
>>
>> - This iterates a few times
>>
>>
>> Some of the constructs may be a bit confusing and maybe not relevant to this
>> issue, but I left them in the test-program anyway
>>
>>
>>
>>
>> Issue #1 sometimes occurs in line 35 (printed as 36) we get ENOENT (No such
>> file or directory) despite that the pipe was just created and the read
>> descriptor successfully was opened
>>
>>     *wfd = open(name, O_WRONLY);
>>
>>
>> Issue #2 sometimes occurs in line 73 (printed as 74) we get EBUSY (Device or
>> resource busy) when attempting to open a non blocking descriptor
>>
>>     const int wfd = open(name, O_WRONLY | O_NONBLOCK);
>>
>>
>> Issue #3 sometimes occurs somewhere unknown and the main process just get
>> stuck (I've failed to reproduced that with strace or so) and to not have any
>> more input so maybe this should be left out ?
>>
>>
>>
>> I hope this is well described and hopefully it's enough to reproduce the
>> issue(s) and hopefully is not due to a fault test case ;-)
> 
> I'm just in the middle of fixing some bugs that are probably related.  I hope to 
> have some fixes in the next day or two, as well as better error codes.  (The 
> error codes are mostly translated from NTSTATUS codes and often don't reflect 
> the real problem.)
> 
> By the way, I really appreciate all your testing and bug reports.  The FIFO code 
> is fairly new and hasn't gotten any intense testing up to now, especially in the 
> non-blocking case.

I've made some improvements in the opening of writers, which I will push soon 
(probably tomorrow).  I think that this will fix the errors you've been seeing 
when opening writers.  The issue is one of timing.  I hope I've built in a large 
enough timeout so that you won't see these errors anymore.  But if it does fail 
you should see ETIMEDOUT instead of EBUSY or ENOENT.

But there's a separate issue: Your program has two processes trying to read from 
/tmp/pipe_parent at the same time.  My implementation of support for multiple 
readers is not yet finished, so this can't work yet.  I hope to have at least a 
first cut of this done within a few days.

Ken