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

[Ken Brown <kbrown@cornell.edu>]

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.

Ken