open write descriptor on named pipe sometime results in ENOENT
Ken Brown
kbrown@cornell.edu
Sun Apr 19 01:46:58 GMT 2020
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
More information about the Cygwin
mailing list