open write descriptor on named pipe sometime results in ENOENT

[sten.kristian.ivarsson@gmail.com]

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 ;-)



Kristian

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: family.cpp
URL: <https://cygwin.com/pipermail/cygwin/attachments/20200418/86bae65d/attachment.ksh>