On 4/8/2020 8:53 AM, Ken Brown via Cygwin wrote:
On 4/8/2020 4:52 AM, sten.kristian.ivars...@gmail.com wrote:
On 4/7/2020 2:38 PM, sten.kristian.ivars...@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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

Reply via email to